Your procedure seems backwards.

If you store the seed of the password generation in a database, anyone who gets access to the database will be able to generate the same password. You still need to get it out and remember/store it, so there doesn't seem to be an advantage over generating a normal random password and storing a hash of it. This would necessitate a brute force or dictionary attack to find the password, even if your database leaks.

Additionally, I would suggest that a better fit for your use-case might be asymmetric keys – the computer would generate an authentication key-pair, store the public key and send you the private key for later authentication (cf. ssh).

---

If you *do* need to generate a normal password / passphrase from a SHA-512 hash (or any seed material), it's a fairly mechanical process:

1. Choose the alphabet (or dictionary). For passwords you might use hex or base64, for passphrases any conveniently sized dictionary will do.
2. Choose the bit-strength. 128 bits is sufficient, but may result in quite long passwords. OTOH, there's no use making it longer than input entropy.
3. Consume the input bits to generate characters/words until you have a sufficiently long password. With a hashed input like SHA-512 you can just use the first bits from either end, with a non-mixed seed you should probably hash it first.