Most encryption algorithms are already comparatively slow and judging success is also much more difficult. When you are trying to determine the input for a hash, you know the desired output. When you are trying to crack encryption however, you don't generally know the desired plaintext, even if you do, the potential input space is generally much, much, much larger.
Each digit of a password is only worth about 7 bits of entropy, even if ideally randomly chosen. Even the low end of a standard symmetric key generally uses 128 bits of entropy. The speed of hashing wouldn't matter much if everyone used truly random 18 character passwords. Plus, the plain text you need to reach is generally unknown to the attacker and encryption algorithms generally operate a bit slower anyway since they have to do more complicated operations on a longer set of data.
So, in a sense, no, there aren't algorithms designed to specifically be slow as a design goal, but they don't need to be as the level of security provided and the normal speed of the algorithm doesn't need to be slowed to be practical. A brute force attack against a well chosen key on a 128 bit encryption algorithm with no systematic vulnerabilities would already take longer than our sun will be burning, to say nothing of 256 bit keys (which would not be done on current hardware before the heat death of the universe). Going slower simply isn't necessary.
If you were to use a key derivation function for a password derived key, that would need to be slow, but you wouldn't want to make the decryption itself slow as that would be inefficient.
As for SSH private key storage, it would depend entirely on the implementation of the key derivation function, not the speed of the encryption algorithm, but I'd suggest probably at least 10 characters if you want it to strongly resist brute forcing even for a reasonably slow key derivation (I'm not sure what SSH private key storage uses, and it may vary by client.)