Is this passwordless system secure?

No, this doesn't seem secure.

Collisions

Mersenne Twister is a deterministic RNG, so it's not suitable for most cryptographic tasks (although it's usage makes sense, because if it weren't deterministic, your approach would of course not work).

In this case, collisions would not happen at the stage you assume and base your calculations on. Instead, they would happen when you limit the ascii value to 10 digits, so the probability of collisions is way higher than you assume.

Comments on Approach

What you have is basically a home-made hashing function. You take some input, you apply some function(s) to it, and receive a fixed-length (3 words) output. The input space is larger than the output space, and it is impossible to reverse the procedure (get the password from the three stored words).

Don't roll your own and Don't be a Dave apply. To properly hash passwords, see How to securely hash passwords?.

You are still implementing a login and registration system (a user needs to enter username and password, you store it in some form, and can then later compare the stored value to newly entered values to authenticate the user).

If you would stop at this step: "The password is sent to the server where a hash is created", you would have an ordinary process. But instead, you add additional steps, which do not increase, but decrease, security.

You start with a username + password hash, with the latter hopefully being a cryptographic hash with at least 256 bits. Then you turn it into a 10-digit number, throwing away all but 33 bits. You then use this as a seed for a pseudorandom number generator to compute a 48-bit key of words, but the information is already lost -- you can't stretch 33 bits into 48 bits, there will only be (at most) 10^10 possible choices for the three words. So your method, even if well-implemented, gives up a lot of entropy for no benefit. You might as well require that users have 7-letter passwords without uppercase or symbols.

Aside from mathematics, your system is insecure due to user assumptions. Ordinary users do not generally treat their username as a secret. Most systems do not hide it from other users (e.g. on this very site we can all see each others user names). Your users will have no inclination to not sharing it, and will not understand that you are logging them in through this username (they will naively assume there's a cookie or certificate or something that's doing an automatic log in).