The team I work in at Microsoft (Microsoft Solutions for Security and Compliance) is looking into the possibility of a solution/tool to help with creation and lifecycle management of email and security distribution groups. See outline below - would enjoy reading your thoughts:

Creating and managing groups within an organization requires unnecessary administrative overhead.
Administrators use valuable time creating groups that could otherwise be used for other IT activities.
End-user productivity may be hampered by delays in processing requests for creation of groups.
End users find it frustrating that they cannot create and manage groups that have meaningful names and users find it hard to manage especially for adding and removing users.

The proposed solution would provide end-users with the ability to create and manage groups through a simple self-help Web portal.

Some of this can already be accomplished by using group managers in 2003.
This allows the delegation of some of this reponsibility to trusted users within the department.
It is also possible to copy user accounts and copied accounts have the same group memberships as the original account.
If people are insistant on being able to perform these tasks a custom MMC can be created and AD tasks delegated in DSA or ESM.
Lastly my preferance is to keep non technical users away from admin duties or you end up with groups added to groups and questions like 'so why can't I add the domain local group from domain X to the global group in Y'.
A further issue I'd have would be non technical users often decide to implement their own naming and security policies that are not inline with the companies as they 'get in the way of business'.

Here is more information based on questions and comments I've received:

I've looked at various identity and access management tools to add workflow and automation for the provisioning of user accounts and privileges. These tools also provide self-help for password resets.
[secguide] Not part of scope

Eventually I'll implement a commercial tool, in the mean time we've defined our various roles and responsibilities and implemented a rudimentary tool. I'm not certain this is what you're getting at though.

As you've pointed out, there is a certain amount of support required to maintain these groups (especially since membership is used to control access to some sensitive applications). We've chosen to delegate our human resource department to specify the role that propagates pre-determined permissions (i.e. group memberships) since they are always involved when an employee joins the company, leaves or changes roles (HR updates the payroll department with salary additions, deletions and modifications).
[secguide] This is a ‘best practice’ for lifecycle management of groups and would be most likely would be covered in our solution.

I'm trying to think about a practical use for an end-user to create and modify security groups. Is this for shared email distribution lists, NTFS file permissions on network shares or some other application?
[secguide] All of the above. Scope is not currently defined as to all classes of groups; Distribution Groups are used primarily for distribution lists within messaging environments but will include both security (share permissions) and distributions groups; Security Groups are used for resource permissions.

Some of this can already be accomplished by using group managers in 2003.
[secguide]This allows the delegation of some of this responsibility to trusted users within the department. Not end-users though, this tool will enable end-users to create groups.

It is also possible to copy user accounts and copied accounts have the same group memberships as the original account.
[secguide] Most likely out of scope for our tool.

If people are insistent on being able to perform these tasks a custom MMC can be created and AD tasks delegated in DSA or ESM.

Lastly my preference is to keep non technical users away from admin duties or you end up with groups added to groups and questions like 'so why can't I add the domain local group from domain X to the global group in Y'.
[secguide] This can be handled by the approval process; (administrators can verify users are requesting the correct groups).

A further issue I'd have would be non technical users often decide to implement their own naming and security policies that are not inline with the companies as they 'get in the way of business'.
[secguide] Not sure if we can solve this for all customers.

DL/DG management is not a new issue by any stretch. It gets new life because the DG can now also be a SG which makes it more important to understand the ramifications of creating a new DG.
[secguide] Yes!

The Dev team should well aware of such things and should also be familiar with the Microsoft solutions used in-house (which are not always available to the public).
[secguide] Yes, thank you.

Personally, if they're going to roll a solution for group management, don't limit it to those using Exchange and therefore have DG's that are also SG's.
[secguide] We plan on it

Make it a group management function (preferred not to be based on expensive DB technology) that encompasses customers of AD (the common denominator).
[secguide] Yes, this will be AD based.

It would not bother me if there were added functions that you could get with Exchange deployed, but don't make it so you have to have it.
[secguide] We don’t currently have a requirement to have Exchange for this to work.

Any solution created should have the ability to be self or centrally managed
[secguide]looking at making this configurable; no decisions yet
in an organization with 1 or more DC's and 1 to 500,000
[secguide] out of scope… enterprise class tool; scoped for 1K – 10K users
users (or more?)

There should be audit ability as well as the ability to send reminders and validation flows of group membership along with the ability to set business logic rules.
[secguide] Workflow is part of the solution that would ensure validation and auditing. An example of that would be to require an owner for every group created.
[secguide] Required and in scope

That owner MUST have an account in the AD and it must be active. If not, there must be some sort of override else the group is automatically removed from circulation.
[secguide] This is part of what we will call ‘lifecycle group management’ and would deal with expiration of groups; orphaned groups etc.

This would help greatly with things such as SOX compliance as well as other compliance efforts. Another need to have would be the ability to have the creation of groups follow a pre-defined naming standard.
[secguide] Not sure how this might work… ideas here?

Nice to allow users the freedom to create groups with any name they wish, but that doesn't help with the greater good in an organization over 100 people. Surprisingly (not really) if you put 100 people in a room and ask them to come up with meaningful names for groups, you'd get 101 names for the same group you're going to create. That would be fine in a Yahoo! setting but for corporate use it's unpredictable and next to impossible to manage or worse, troubleshoot. Good naming standards are the responsibility of the corporation's architects and it's up to those standards creation processes to come up with meaningful and useful naming standards. Not the consumers of the service. At least, not if you intend to keep the service available and able to be troubleshot in a timely manner. Besides, who would win if two equal folks decided they wanted the same name for a group? [secguide] We could implement first come, first served.