I have used gpgsm --gen-key to generate a certificate request based on a Ed25519 key stored on a Gnuk token.
The certificate request can't be processed by OpenSSL (tested with 1.0.2o and 1.1.1-pre7):
Check that the request matches the signature error unpacking public key 140413640283904:error:100D7010:elliptic curve routines:eckey_pub_decode:EC lib:crypto/ec/ec_ameth.c:150: 140413640283904:error:0B09407D:x509 certificate routines:x509_pubkey_decode:public key decode error:crypto/x509/x_pubkey.c:124:
My understanding is that OpenSSL expects the Ed25519 public key in the CSR to be represented in the format specified in the draft-ietf-curdle-pkix draft, which is different from the format used for other ECC keys. Other ECC keys are represented as a ecPublicKey algorithm identifier (OID 1.2.840.10045.2.1) followed by the curve identifier, whereas (as per the aforementioned draft) Ed25519 keys should be represented solely by the new OID 18.104.22.168.
To illustrate, here is the relevant portion of the CSR generated by GpgSM (as analyzed by OpenSSL's asn1parse):
122:d=2 hl=2 l= 58 cons: SEQUENCE 124:d=3 hl=2 l= 20 cons: SEQUENCE 126:d=4 hl=2 l= 7 prim: OBJECT :id-ecPublicKey 135:d=4 hl=2 l= 9 prim: OBJECT :22.214.171.124.4.1.11591.15.1 146:d=3 hl=2 l= 34 prim: BIT STRING
and the corresponding portion from a CSR generated with OpenSSL 1.1.1-pre7:
107:d=2 hl=2 l= 42 cons: SEQUENCE 109:d=3 hl=2 l= 5 cons: SEQUENCE 111:d=4 hl=2 l= 3 prim: OBJECT :126.96.36.199 116:d=3 hl=2 l= 33 prim: BIT STRING
I believe one place to fix this would be in libksba's _ksba_keyinfo_from_sexp function (src/keyinfo.c), where Ed25519 keys should be treated differently than other ECC keys.