I'm afraid what you're asking doesn't make a lot of sense.
If indeed you already have the set of numbers that compose your private key, then all you need to do is express that as a string. And if you can already do that, then what do you need openssl for? And if you can't do that, then how are you going to communicate them to openssl? Typically if you actually have the data at all, then you also have the means to output it into a standard file format.
The standard key format used in x509 is simply ASN.1 data formatted using DER (binary) or PEM (base64) formatting rules. Here's a fun activity to see what it looks like:
$ openssl genrsa > key.pem
Now we have a 512-bit RSA keypair. Not particularly useful, but small.
$ openssl rsa -text < key.pem
Private-Key: (512 bit)
publicExponent: 65537 (0x10001)
So that's your private key. The first two fields; the modulus and publicExponent are also your public key.
How is this stored? We can ASN.1 decode it without additional processing:
$ openssl asn1parse < key.pem
0:d=0 hl=4 l= 316 cons: SEQUENCE
4:d=1 hl=2 l= 1 prim: INTEGER :00
7:d=1 hl=2 l= 65 prim: INTEGER :CC959AA2AC036B77...
74:d=1 hl=2 l= 3 prim: INTEGER :010001
79:d=1 hl=2 l= 65 prim: INTEGER :91D1B03E724C9DB4...
146:d=1 hl=2 l= 33 prim: INTEGER :E831F72E74263DDC...
As you can see, the file simply contains the expected data fields dropped in there one after the other, with no fluff. As long as you have the right ASN.1 identifiers for each field, you're pretty much done.
Of course, if you don't want to bother with the binary encoding rules, you can read the ASN.1 fields in as text using the "conf file" format described in the documentation for
ASN1_generate_nconf. It looks more like this:
You can load this format in to the asn1parse command using the
-genconf <file> option, but I'm not sure the command line program allows you to then output a PEM or DER file from the contents. Though, realistically, a C program that uses the openssl API to do just that would only be about 20 lines long, so it's something you could easily do if necessary.
Still, this all sounds pretty contrived; why you would possibly need to do this is beyond me. But I would imagine that if you were well-versed in this technology enough to know that you did need to do it, then the writing the appropriate utility to do so would be trivial.