Hear, hear! ++

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.

some method for us to attach preentered data about that user who has not yet accepted the invitation.

That's easy enough; on these cards, give folks a short "Invite Code", and a standard URL for account creation -- this is one less chunk of initial info than the "username + password + URL" you have, as well as slightly more secure -- your commentary does not explain how you intend to defend against someone other than the user getting their hands on someone's card.

The "Invite Codes" act as one-time pads for creating that initial acct., and passing the data on -- this is similar to the "two forms of authentification" methods that recent legislation asks banks and other financial institutions to implement for Internet-based activities. Having the one-time pad also means that, if your database is hacked, at least the preexisting data is NOT tied to specific people and logins.

Your comments seem to underline security, yet because you have a guessable scheme, a kid with a half-day off from work could suss out the overall scheme, and start a dictionary attack to guess usernames and passwords. This is unwise; note that most high-security areas do not pre-generate userids or passwords, and this is one of the reasons.

Reference the other comments about forgetting usernames and passwords for that, as well, so be ready for most of your Internet-unsavvy users writing the information down on Post-It notes. As someone who did Tech support for years, I 2nd, 3rd, and 4th that the harder it is to remember these things, the more they are written down, and the harder it becomes to secure your environment.

Overall, I think your emphasis on "ease of use" does not factor in real world conditions. If your service is "good enough", people will be happy to deal with a simple login and registration process. Building real trust and interest, in my experience, comes not from making logins that any script kiddie can suss out, but from building a solid foundation where people feel comfortable with the program in question. AOL tactics worked for AOL, but the millions of floppys, CDs and DVDs with AOL software, and their declining share of the market, say something as well. I strongly suspect you'll spend better money on an infrastructure that's easy to use _and_ secure, over mass, or even semi-targeted, mailings.

----Asim, known to some as Woodrow.