Which is the best practice to adopt for registration passwords?

If you allow someone to type in the registration passwords and username upfront in the registration form of the sign up process and have them working immediately, then you have a problem when it comes to notifying your user for any reasons, if they are not notified by your messages in the provided e-mail. There are many reasons why it could happen, including:

the user informed the wrong e-mail (typo or any other reason); the message is going to their SPAM folder; your system is not authorized by the user to send her any messages: some e-mail providers have some system where they would reply automatically with some e-mail providing instructions on how to proceed to get the messages delivered, in order to protect against most SPAM. Maybe the user would have to set up some exception in order to not require those steps from some senders; the mailbox is full; Whatever the reason is, if the application requires e-mail validation in order to allow the user to access it then it's less likely your system will be unable to deliver messages to your users. Sending multiple e-mails to invalid users may increase the chances for your e-mail delivery system be automatically flagged as SPAM, and you don't want that.

There's another problem to consider. What if the user provided another valid e-mail due to some typo? Then there would be another user getting all those annoying messages. Or that other user could even take over that account if she would desire so. Those are some of the reasons why e-mail verification is desired.

So, one approach to user authentication is to simply ask for the user e-mail address in the first step of the sign up process. Don't ask for anything else to not bother the user registering to your application. Just the e-mail address. Then they would get a link with a generated random token valid for a few minutes. Once the user clicks the link she would be taken to the next step of the registration and that e-mail would be flagged as confirmed.

Something to consider in this approach is that someone could use this to, intentionally or not, SPAM another user with annoying messages asking the user to proceed with the sign up they haven't requested. I'm not sure how to prevent that, but it's probably a good idea to rate limit those messages. For example, a token could be valid for 10 minutes and while it's valid the system wouldn't send another token by e-mail. Those users could be still annoyed by messages every 10 minutes, but maybe you'd want to handle such cases once they happen.

There's absolutely no reasons to send any passwords to e-mails for recovery purposes. Tokens should be used instead and then the application could ask for a password. Just be aware that a password is not really required to authenticate a user if their e-mail address is valid. They could always request a token when they want to sign in, without ever providing a password.

If you still prefer to have the sign up full form displayed up-front, there's also the possibility of requiring the user to confirm their e-mail address in order to being able to get any messages delivered to get any messages delivered to them. This way, the system would never attempt to send any messages to unverified e-mail addresses. Whenever they are using the application, a notification icon could be shown to remind the user that her e-mail address is not yet verified, which means she wouldn't be able to recover from a lost password or get any notifications from the application by e-mail.

Also, be aware that usernames are not really required if you set a unique constraint on the e-mail address so that the e-mail could be provided instead of a username for authentication purposes. You may want to keep the e-mail addresses in a separate table in order to support multiple e-mails per account.