My thinking here has been that there should be one “first class” Ethereum-native profile that users either create or bring with them during onboarding, and that profile can then link out to or pull data from other profiles like BrightID, Keybase, Twitter, LinkedIn, etc, if those profiles contain important/relevant contextual information. Your proposal sounds similar to what I’m looking for in a profile solution, so it has a preliminary 
from me!
I haven’t done much work with ENS, but it seems like your proposed solution would be quite easy to pull off because we would just ask you (the user) if you’d like to integrate your ENS name, if yes, we pull that information and store it as your “name” in 3box.
I think a tight link would be nice (necessary, even) in that I should be able to use someone’s ENS name to securely look up their profile. With this, we could effectively build a decentralized Keybase-like system where names securely map to crypto keys and other identity metadata. This should be possible using ENS’s Public Resolver tool (discussion and tutorial thread here). Without this tight link, I’m not sure how we would be able to resolve the name to the profile in a decentralized, secure, “trust-minimized” way.
A challenge that arises is that of data mutability. Let’s say we link the ENS name to the profile using the IPFS hash of the profile. When the profile changes, the hash changes, and so an on-chain transaction to update the ENS resolver will need to be made each time the profile is modified and saved. This puts heavy load on the blockchain and becomes quite expensive over time.
What we would do to solve this (and I am borrowing from the Blockstack design whole cloth here) is to create a layer of indirection where the ENS name is linked to an immutable URI that points to a “zone file” and this zone file is just a json blob that contains two important pieces of information: a crypto public key and a mutable URI that points to the profile data. This mutable URI could be for example an HTTPS URL or an IPNS hash.
The profile rendering tool would then use the ENS name to look up the zone file, and use the zone file to look up the profile data, and ensure the validity of the profile data by making sure it is signed by the public key referenced in the zone file. Whenever the profile is updated, the mutable URI doesn’t have to change, so the zone file doesn’t change, and no on-chain tx is necessary to update the ENS mapping.
(This blog post, and the first graphic featured, explains how this works in more detail.)
It’d be cool if Ethereum had a native, scalable profile system that worked like this. But it doesn’t! So now we get to build it (or help 3Box build it) 
