This has been an issue for many users for some time, but now I have created a solution for a client that I thought I would share here. The issue is that the DNN User Accounts does not permit changes to the accounts by non-admin users. (Personally, I think this could be fixed by not letting non-admins assign users to the Administrators group, but I may be missing something). Anyway, I needed a solution to have one group in HR administer users and now I have it. It takes some work, but is fully within the DNN core constraints and withstands all upgrades to new DNN versions. This is a primarily cosmetic solution to enable a few individuals to do their job without more distraction on the screen than they would like. Here is what I did...

First, you have to give in to the fact that the user managers (I call them the User Managers group) are technically required by DNN to be in the Administrators group. We trust the people in the User Managers group, but the real problem is that we don't want to train them in full site administration (and they don't want that either). They just want to maintain the list of users. So be it.

1. Make a new group called something like User Managers
2. Add the person or people who will be maintaining the user list to both groups: Administrators and User Managers. (You may want to start with just a test user and add the others later.)
3. Create a new page for user management in your menu structure just for these managers. I created a new top-level tab called Managers and put User Management as a sub-page within it.
4. Set permissions on your new user management page so only members of the User Managers group can view it (View permission).
5. Add Existing Module (without using the "Make a Copy" checkbox) and find the User Accounts module on the Admin/User Accounts page. This will add the User Accounts grid to your new page.
6. You may want to optionally add a text/html module above it to explain how to edit the list below (optional).
7. We will remove the manager's ability to edit any other pages, but on this page they must retain that ability for user editing to work. Therefore, we will restrict all Administrators from seeing the Admin and Users buttons on the control ribbon at the top. The Modules and Pages buttons (menu items) will still be functional so we can add more modules and pages to this page if desired. To remove the Admin and Users menu buttons for all Administrators, go to Edit Page, Page Appearance and then scroll down to the section: Page Header Tags. Add the following code and save:
   

       <style>
           #ControlNav,
           #ControlActionMenu li:last-child {
             visibility: hidden
           }
       </style>
       

8. Now for the tedious part. The real objection to making the Managers be Administrators is that they can edit any page, and they see the edit ribbon on all the pages. We have taken care of part of that problem on this new User Management page, but now we need a better solution for all the other pages. Go to each main page on your menu (each top-level menu page) and change the permissions so that members of the User Managers group are blocked from editing it. Set the View permissions for that group to a check in the checkbox, and set the Edit permissions to a bar (not allowed) in the checkbox. This will prohibit members of the User Managers group from being able to edit the page. Then use the button called "Copy Permissions to Descendants" to put the same permissions on all the lower pages in each of the main menu structures.
9. Add a test user as a member of the User Managers group and login as that user. Test all pages to ensure functionality where required and limitations where you expect them.

That's pretty much it. Now members of the User Managers group will experience the website as they always have, but they gain access to a new section just for maintaining the user list. If you have done everything correctly, they will not be able to click on anything that takes them to the actual Admin section of the website. Of course, this is meant for a well-behaved group of managers. If any of them paste in a URL for the Admin section, they will have access. As mentioned above, this is a primarily cosmetic solution to enable a few individuals to do their job without more distraction on the screen than they would like.

Not sure why you would say that, Sebastian, since basically all it does is restrict some members of the Administrators group from editing most of the pages on a site... specifically, those also in the User Managers group. It is those administrators who don't want to be involved with full site administration, but focus only on adding and removing users. It lets them do that and hides other site editing and management functions from their view.

The solution you mentioned may become a good solution one day, but as of now it seems to have a number of  serious unresolved issues.
https://github.com/DNN-Connect/UserAc...

 Object reference not set to an instance of an object. 
 #39 opened 5 days ago by dstarr1213

 not suitable for sites with larger user base 
 #38 opened on Dec 9 2015 by sleupold

 Error after adding, deleting and restoring a user 
 #37 opened on Nov 6 2015 by tdgarvey

 Hard Delete Results in Critical Error 
 #36 opened on Aug 14 2015 by vnomus

I needed something that I knew would work right away using standard software and would not involve any third-party modules. This solution delivers on those requirements. I support your work and will consider upgrading to it when I feel it is stable, but for now, I have a solid, stable solution.