I think @simonw clearly explained the problem around the login flow: "resist the temptation to innovate around login!". But I'd like to add more from this.
First, this will always depend on the product you offer. If you target highly specialized tech people, why not, they are most often open to changes. For the rest, it won't never be a good idea.
We tried implemeting a "one time login link" at ImprovMX, like a few others commented here. One drawback we saw was a surge in support requests from people having issues receiving the email, or not understanding how to connect. We could debate on this but definitely, doing something "original" was not a great idea.
But regarding the suggestions made by the original post, I can clearly see a lot (A LOT) of issues:
1. Changing the flow from what the users are used to:
Clearly, once you have entered your email and password, you are expecting to receive an email. It's probable that a small percentage of users will close the window once they see the next page asking to send an email, without even reading it, loosing the "mailto:" link with the special token.
They will also be lost on what to do; They'll expect an email, and won't understand the need to send one.
In a more broader sense, changing the flow will require the users to think harder than usual on what to do, causing more users to leave and never finish the registration form
2. Matching the proper email
If they happen to click on that mailto, they will have to remember which email they entered in the form, and will have to keep that in mind when sending the email. For me, if I click on a mailto, I'll have a GMail tab open to send that email, and I have 5 aliases registered. It will require an extra caution to select the appropriate one.
3. Having that email available
If the user registers via his phone using an email not configured on that phone, he won't be able to send an email on that "mailto". This will require to copy/paste the link (and copying a mailto on a browser results in A LOT of changes on what is copied), find a way to share that copied data onto a device that has the appropriate email configured.
4. Custom emails
Some users enter their email using the specialty of Gmail, such as user+label@gmail.com. When they'll send an email, they won't be able to add that "+label", causing the account creaton to fail
5. SPF/DKIM/DMARC, seriously?
Wrapping your head around how these 3 standards works requires significat efforts. And yes, without them, you can not guarantee that the email is truly send by that domain. But still, many custom domains doesn't have a proper DMARC implemented and they can still spoof your account creation. In order to avoid this issue, the only best way is to keep the original flow : the services sends an email to the one the user gave.
Definitely, this is not a good idea to implement for so many reasons, but I agree on the original thought: The current flow has its own issues that needs to be resolved.
One flow I prefer, that doesn't fix everything but still remove a lot of headaches, is to send a code by email when the user has hit "Create my account". The next pages shows that the service expects the code sent by email. Once the user receives the code by email (ideally, having the code in the subject), they can enter it in order to validate their account and they are then automatically logged in a fully activated service.
This removes a few issues, such as:
Not having the email account configured on the same device
Ending in a splash page right after creating an account
Ending in a splash page when clicking on the link in the email
Havign to connect to the service even though you did all the proper validation (I hate that)
The only issue remaining is to ensure the email arrives quite fast. But as long as we need email verification, we will have a hard time fixing this, as it is outside of both the service, and the user hand.