If that is your intent, you can treat this like a regular website "remember me" feature. Generate accounts with no initial email/password (making them impossible to login normally or recover!), which can be filled in later like a normal account update / password change. You might also want to delete such accounts periodically if there has been no recent login. You also want to be sure search bots and the likes don't keep getting new accounts generated for them.
Your server side web platform likely provides most of the required components directly, and has well tested libraries (which would also likely give you things like Facebook and Google login).
"Remember me" tokens are generally a random value generated by the server and stored in the database in a hashed form (so that in the event of a read-only DB leak, the attacker still cant login), while an original copy is provided to the client. But an alternative is just to have a long lived regular login session token/cookie. The email/sms/etc. verification and password reset features use similar hashed tokens as well, but instead of storing in the browser it is emailed, texted, etc. to you. In the case of short tokens for manual entry (e.g. SMS) be very careful about brute force attacks. All are likely readily available in tested forms for you with suitable protections.
Passwords should absolutely be suitably hashed by a secure algorithm (and no, even a secure hash like SHA256 or such by itself is not enough) when stored on the server, since as well as protecting yourself from a data leak, people tend to reuse passwords and they tend to be words.
As for session logins themselves, there are several options, so check what you are using. Some may just store an ID in a cookie (then the server must look this up every request against a centralized store), while others store the actual data in a protected form (signed or encrypted. This gives the server everything it needs and doesn't need a central session store).
JWT itself is fairly complex and has some pitfalls, if your framework already provides something, or has well known libraries for user authentication, I would recommend that rather than your own JWT.
For a start this is not really the right concept for JWT, generally the token would contain the username/id, etc. itself. In fact one of the points of JWT is that server A can authenticate the user and give the user the token, then the user sends the token to server B. Server B uses that to know who the user is without asking A. This means all the tokens generated by A are using the same key so that B is able to validate them. If you only have one server, or you intend for B to ask A, then what is this adding? It could have just been a large random value.
This is actually based off a lot of existing technology but standardised to be usable between different platforms which may be using different languages, written at different times, by different people, and to cover the situation where server B trusts A, but A does not trust B which all sounds great and secure. But still, there are a lot of security pitfalls with it so be very careful. For example B accepting very old tokens that were maybe lost, or allowing insecure algorithms allowing for token forgery. Perhaps the worst case being servers that accepted tokens with the "none" algorithm as valid, or if using a public key, allowing the algorithm to be changed to a symmetric one (using that public key as if a secret key...).