Well, in a site I'm working on I ...
1. created a relseg called "content editors" on the membership group for my subsite.
2. granted write permissions on the subsite to members of that relseg.
3. added my content editors to that relseg
All using the existing groups and permissions admin UI.
However:
1. That UI really sucks, and if I didn't know how things work under the hood I probably couldn't use it.
2. The acs-subsite/www/members membership management pages are sorely lacking.
You can think of a relseg as being a lightweight mechanism for making subgroups, for slicing groups into pieces in other words. You can think of the name of a relseg as being a role ... or you can use the role capability of the underlying acs-rels datamodel if you want (the membership management pages might work better if you do, by coincidence I'll be looking into this for some admin pages I'm doing for a client over the next week or two).
This is one area where .LRN actually got things more or less right, using relsegs to define professors, students, etc.
Rocael just posted a suggestion for dotlrn-specific permissions templates which boils down to saying "the subsite ones are insufficient". Dave and I have both suggested that the right thing to do is to fix acs-subsite.
Likewise I think an enhanced UI such as Ryan describes should be built into acs-subsite rather than exist as a separate package.
And, Ryan, I suspect that what you want to do can probably be done with the existing datamodel.
If I have some time I'll try your UI in the next few weeks I hope. I think for now I like the idea of trying to get the UI right, to see what a user-friendly UI might look like, than to worry if you've created some unneeded datamodel bits. If the UI's right, perhaps a couple of us (dave and I, perhaps?) can help figure out how to map that UI to the existing datamodel if it's possible to do so ...
I'd love to see this UI improve.
