# Can private key be specified on key pair creation?

Without regards to any specific implementation of asymmetric cryptography, I am wondering if it is feasible to come up with a value of private key I want to use, and calculate the corresponding public key from it.

The use case would be the creation of multiple private/public key pairs where the private keys are merely the concatenation of some masterSecret and the pair ID (the latter is publicly known). This way, whoever knows the masterSecret also knows all the pairs' private keys. This, in essence, makes the owner able to have multiple public keys linked to just one private key, which is ordinarily not possible.

Which asymmetric cryptography implementation/algorithm is reasonably practicable for this purpose, given that typical use for the calculated pairs would be SSH-like authentication?

You can use Elliptic Curve cryptography. Here the private key is a vector $d$ ($s$ is also used sometimes) and the public key $w$ is calculated using $(x_w, y_w) = d \cdot G$ where $G$ is the base point (part of the domain parameters) of the elliptic curve.
To generate the key from the master secret you can just use $K_O = \operatorname{KDF}(K_I, C, L) \mod N$ where the input keying material $K_I$ is set to the masterkey and the Context or OtherInfo $C$ is set to the pair ID. Finally $L$ is the output size in bits, it should just be set to the number of bits in the curve so that the output key material $K_O$ will have the correct size. HKDF-expand would be a KDF that is a good fit for performing the key derivation.
The one thing missing is that you should convert the output to a value between $0$ and $N$ with $N$ the order of the curve. There is a description on how to do this in NIST SP-800-90 Arev1, appendix A 5.3 (the simple modular method). For most curves simply performing $d = K_O \bmod N$ should also return a private key that is random enough (what I would call the simplest modular method) but beware of attacks against certain schemes, sometimes it is worth to go the extra mile.
Note that there is a drawback to creating key pairs this way: the $\operatorname{Gen}$ function is often designed to use a random number generator, not a static value. The generation of private keys may also change between implementations (e.g. big / little endian machines, functions to test the random number generator etc.). So you need low level access to the private and public key generation functions (or just to the point multiplication function, of course).