[aiiane]

That's a very binary way of looking at it. Depending on the sign up flow, it may be much more difficult to discover the existence of a username or not, than it is in the login form. (For instance, if the signup flow involves payment details before the username step.)

[mistercow]

Are you going to enforce uniqueness of payment details? And if so, what part of those details must be unique? Will you require a unique credit card number?

If so, you will have to maintain either a bloom filter or a list of hashes for all eternity to ensure that nobody signs up twice with the same CC number. [Edit: actually, you could keep the scrambled CC data for a finite length of time if you're just trying to rate-limit, but still see below]

So suppose you've done all that. Are you going to do a test charge to see if the credit card number is valid before allowing the user to choose a username? If you don't, your efforts are wasted, since anyone can just use a CC generator (they're used for testing) to sign up for new accounts all day. If you do, you've probably driven away 99% of your users with your ridiculous signup process.

[jfarmer]

If you're using a third-party payment provider like Authorize.net or Braintree to store CC numbers, you'll be given a unique token from the provider when you add the CC number. When you add the CC you can also have the provider run and immediately void a dummy transaction to verify the card is real, too.

[aiiane]

I was actually thinking of cases like MMO game accounts - often times the actual game account isn't created until after the game is purchased.