Side note: usernames should just be emails these days, they're unique and save all the effort of needing another made up name.
A username/real name can still be used as the "name" if this is an online community or something similar.
It may not sound like a big distinction, but there is a big distinction there. Instead of your username being your email address, they've abstracted the authentication from the core user record such that usernames are not used for authentication, so don't have to mutate if the authentication identifier (email address, phone number) changes, just some auth settings. This is obviously a much more extensible and robust way to deal with authentication over time, but it's also obvious it's much more complex than a simple username/password pair.
Re: implementation - I don't see the big distinction. These are all just related properties of a master user id number. Those properties can be anything and any of them (in any combination) can be used to login.
Nope. Most free email providers out there (including gmail) have policies for username expiration, some even quite aggressively (like one month without login). "Me" on one of these services might not be "me" in three months' time, but you-website won't know that and will happily send a password reset link to my old email.
Really, they do.
Same with another site I was on, except the usual solution was seemingly 'find one of the staff on another site they're a member of and send them a message there'. Made for a nice security hole too, since people could (and did) impersonate others and get given their accounts as a result.
You need some sort of email (or other contact information, like a phone number) simply so people can get their account details back in a semi secure way.
With an on-site "Contact Support" form, you can at least compare their IP address with historical login addresses. But that comes with its own weird problems like, for example, a sibling claiming their brother's account from the same household to read their juicy PMs or steal their credits or whatever. Or giving moderators access to more sensitive information and power than necessary.
Password reset being "optional" just means that people are going to use your support system for it when they eventually forget their password or the initial registration session expires. Reddit and HN have optional email while your new website's only user just forgot their password without an email address on file. What are you going to do when they ask for help off site?
And by the time you're fielding SMS and Twitter handle password resets, you may wonder why you didn't just put more emphasis on the email address input field. Now you're polishing your SMS or Twitter handle reset system that has far more narrow appeal/usage than an email system.
Of course, at the end of the day, it depends on the type of service you're operating. But "make email optional" is a trade-off, not universally good advice. Spend too much time in the HN echo chamber and you'll just do things that work against your users.
People can opt out via http://10minutemail.com/.
These days I prefer to require an email address. That way, the few users that want to opt-out can insert a bogus one.
In fact, most of our app users don't even have to sign up! They are invited via sms or email, and given a link that works like a capability. Clicking that link established an account for them and they get a full experience right away, complete with all their followers (people who uploaded their address books and had their number or email in there).
This is instant engagement of the user.
We don't even require a password for when they download our native app. We just go to Safari and do an OAuth 2.0 flow with our own site and give an access token to the app. That access token can be for 100 years.
They only need a password when their cookie expires or if they want to access the site from another device.
In that case, it's good to have asked for the email address or phone number in the beginning. That's the user's identifier.
Our system also works with Facebook connect, etc. but that's not the coolest part. The coolest part is having the user choose their own Qbix app as the identity provider to authenticate with, so they can visit new sites and they are instantly greeted by name, find friends on there etc. without the site knowing anything about them on other sites. That's the holy grail :)
I understand and I'll provide my email address, my JID, my phone number and whatever else I'm willing to provide, if I want someone to contact me. But contact details are technically completely unnecessary to just have an account.
If you don't want that, use Mailinator and forget about it. It's insurance against stupid support requests is what it is.
Lesson here for anyone wanting to use emails for usernames:
Make it really clear that you're asking for the email as an ID, as the username. Otherwise this will incline people to enter the same password as their email because they think they're asked to log in. Even if they know it's important not to re-use passwords over different logins.
To make this anecdata N>1, I teach computer stuff to kids (ages 8-12, generally) and they tend to make the same mistake.
(working on semi-public computers, I am glad I get to teach them about Private Windows: "if it's not your computer, only enter your password on a window that shows the little mask/sunglasses-guy")