i personally have just been implementing:
i create an "extended hash" of multiple digests of sha512 (feeding the password in the hash object, collecting the digest each time to append to our result. You could do this or use a hash that supports different lengths like blake2 (but it cannot be salted!).
so we want a 2048 bit private key, we create therefore 2048 bits (256 bytes) or hash data from our password
we turn this into TWO large numbers, 1024 bits each are converted to the long/int whatever where we won't loose any information (python has infinite precision)
so we now have two huge numbers, for each of them i hunt for the first valid prime from their position by incrementing them and checking if the number is prime.... on average it seems it can take about a thousand checks to find that prime... entirely acceptable
with regard to the safety of this, (we have about 2^512 bits of entropy in a 1024 bit number!... this means that on average p and q will be 2^512/2 values apart. log(2**512/2,10)=153.8 .... so to put this in perspective, in decimal this number has about 153 digits
the concern might have been the same primes would turn up for different passwords, or the spacing of the primes (of which we have no theorems to predict).... but with such a ridiculous average distance between p and q i can't really see the issue
the way it's insecure is it uses a password for a RSA, which can't possibly be as secure as AES as it has to show some of it's information, combining brute forcing passwords with this might compromise security.
HOWEVER, I have seen some similar ideas about and it's something like if you could write your key on paper etc, be able to tell it down a telephone line... many of these sort of things, could, especially for the IT illiterate, in SOME situations, it might improve security. I was sort of imagining niche uses like I could enter a pin into a digital radio to authenticate my identity (they'll never see that information, but they will be able to confirm the pin hasn't changed)