That's actually even more than I wanted but it would also work. I was actually thinking about my implementation and gl_groups would end up having added fields of 'owner_id', perm_owner, perm_group, perm_member and perm_anon with perm defaults of 3, 2, 0, 0. Meaning only owner can add members and users not in the group don't see it. You could unhide the group with a 2 in perm_member and/or perm_anon. And you could make a 'friendly' group where anyone can add members with a 3 in perm_member. Or the membership list could be locked by setting perm_owner to 2. The group could even be hidden from the members with perm_group = 0.
With your delegates idea, perhaps the list of perms becomes perm_owner, perm_member, perm_group_pool, perm_nonpool. Then visibility inside and outside the pool of users is controlled by perm_group_pool and perm_nonpool and perm_member means actual member of the group not the members of Logged In Users.
In my original idea, grp_gl_core become grp_type where 0 is a normal group, 1 is a core group and 2 is a feature-less group. Although perhaps user pools also need a type. Also, with the pool concept, the feature problem perhaps is less important as the pool assigned to the group delegate would also have a set of features. This list of features may or may not belong to the delegate but it is the only set of features he could assign to groups in his pool.
Let's see:
This could be the main user admin or via an email invite to the user
That is a cool balance of lockdown (user admin must do it) and openness (the user decides).