Speaking only as a user and not to the technical details of the proposal, these are my thoughts about what I want for “identity and membership” in Aragon:
I want my org to have an ENS name, and I want Aragon to recognize my ENS name if the address I’m using to interact with it has a name. If I don’t have a name yet, perhaps the app could offer me a way to register one (either a subdomain of aragonid.eth or a fully-qualified domain name - for the latter it would probably refer me to a dedicated ENS registrar app). I also want to be able to use an ENS name instead of an 0x address in every place possible i.e. “first-class” ENS support.
I agree with @jtremback that first-class ENS support is likely the most urgent need usability-wise. I specifically say ENS because creating our own name system seems like an unnecessary detour.
Aside: Regarding the address book app, I wonder if it wouldn’t be better to store this locally rather than on-chain. This has the benefit of 1) not taking up scarce and expensive blockchain storage 2) not requiring a transaction each time it’s updated and 3) not requiring consensus over the name -> address mapping, since each user gets to create their own address book.
I have a desktop wallet app that has an address book but the labels are stored locally, not on the blockchain. This seems to work well enough. See my idea below about a “roll call” app that might make more sense to do on chain since it isn’t storing any extra data on chain or introducing a new shared resource to govern.
It might be interesting for orgs and individual org members to also have a profile that can be seen when you click on the address or ENS name, so you can quickly get more context about who/what you are interacting with. A simple solution could be Ethereum Profiles; storing (relatively) large amounts of data off-chain is a mostly unsolved problem that is currently being punted to centralized hosts like IPFS gateways or AWS. (Swarm incentives when?) Outsourcing this feature to Ethereum Profiles is probably the best solution vs rolling our own (another unnecessary detour imo).
Aside: maybe in the future Ethereum Profiles can also support a standard like ERC-725 so users can make and receive claims, and these claims can be stored in the profile. I imagine this working like an OpenBadges backpack, if not actually using that standard just in a blockchain context (related). This would be a universally beneficial feature for all “social” or “multiplayer” dapps, not just Aragon.
I think the current way that “membership” can be defined in Aragon works great today and is already intuitive. How do you add someone to your organization? You assign a token to them if you want them to have governance rights, you add them to the payroll if you want to give them a salary, and you assign a permission to them if you want them to have direct power over an action. Seems straightforward to me - I see no need for the membership naming scheme described in the OP.
Maybe a “membership” or “roll call” type app could exist that just pulls from the Token Manager and Payroll apps installed in the org and shows who is a “member” and what apps they’re plugged into e.g. “johndoe.eth - Token Manager, Payroll” similar to the way the Permissions app shows which apps are installed and what permissions each entity has in the org.