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 1.3.101.112.

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            :1.3.6.1.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            :1.3.101.112
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.