Another thing that I'll start to experiment with is delayed confirmations.
The confirmation step via emails is one of those things that has been copied over and over, without knowing, in many cases, what problem it addresses in the first place and if it's crucial to one's particular situations.
I think having to interrupt your visit to log into your email, is another speed bump to a smooth registration process.
A better approach, in my opinion, would be to let users just start interacting with your service right away. Give them 5 to 7 days to confirm their account, after which it is automatically suspended. You can let them know the next time they try to login that they never actually clicked the link they received via email a week earlier. The timeframe is long enough that they can actually use the service with no hassle and it's short enough that they won't have forgotten which email and password they gave during registration.
Of course, if the operations they're trying to perform in your site are sensitive enough (e.g. purchase, sale), you should let them know that it requires an immediate confirmation of the email address.
Other unrelated advices:
- if you use the email as a login name, then allow users to have whatever handle they'd like. i.e. don't make the username unique. Also, allow spaces in that field. e.g. StackExchange.
- under no circumstance should you keep an unencrypted record of the password. It's tempting to think that in the name of user friendliness, whenever someone loses their password, you will just send it back to them. As soon as I see my password sent to me in an email, I usually logon to the website, change the password to 12345 and depending of the sensitivity of the data kept by the service (e.g. web hosting), I would consider stopping using it altogether (Ironically, I've had cases of websites telling me that 12345 as a password isn't secure enough for their service, after they'd sent me my password via email).