Using DNS to identify users is unwise, in my opinion, because it means that people won't own their own on-line identities -- they'll have to rent them and for real money, too. And if some users are assigned a sub-domain on a shared domain, their identity won't be portable.
I think it is worth doing a little extra work to make a user name system that doesn't have those problems.
DNS has the virtue of being here now, being tested and refined over multiple decades, and offering a choice between subdomains for free or portability for a nominal annual cost. It's not perfect but it's good.
send email to username@example.net
=> lookup example.net
=> pull MX record
=> route email to example.com
In this context we're talking about what it takes to avoid relying on DNS (because DNS is a centralized, highly politicized system). Your solution would still rely on DNS.
In a truly decentralized system, you're not going to be able to have readable unique names without collisions. Why? What happens when the network splits, then people on either side of the split setup the same username. How do you rectify this when the network rejoins? How do you know that the network has split vs. a node going offline (if you wanted to do something like shut down new usernames until the network was whole again)?
The concern here is that whoever is currently leasing the domain name has authority over users' identities. A better system would let users own their identities outright.
"In a truly decentralized system, you're not going to be able to have readable unique names without collisions. Why? [....]"
This is a well explored topic. A good place to start might be to look up "Zooko's Triangle" and then go forward from there towards various ways people have figured out to deal with such problems. (Zooko's wasn't the last word.)
[1] - https://code.google.com/p/webfinger/wiki/WebFingerProtocol