This is not desired for a few reasons

1. It requires a user to be present at the time of the accounts creation. In our case we need to invite a user to log in to create the account, and that in itself would require a username of sort - or some method for us to attach preentered data about that user who has not yet accepted the invitation.
2. It makes the assumption that we want to allow people to annoy themselves with the chore of guessing their user names
3. After a user initially logs in we will have a 'request name change option' - we might anyway
4. we want to make a statement with their login ID to earn trust, kind of like shouting 'l00k how l33t and caring we are, we custimzedzzz you a username', which is partly true, we are trying to stress the ease of migration
5. The market for this product is people who probably don't remember what their 'internet login thingy' they chose was to begin with. So they are not likely to have an emotional attachment to their u/n.

In the real deployment the username collisions will be much less likely because we will factor in domains. However we want to use the aol tactic and send out invitations to our service on both customized business cards, and demo cds and the backend must have the precompiled data we have aquired for that user - business locations and other good stuff.