You can use an LDIF file to import the data, provided you have set up the attribute correctly in the schema.
This howto you've referenced is for setting up a keyserver with LDAP as a backing store, not for adding PGP keys to LDAP users in your existing schema. The difference is important, because in the referenced schema, PGP keys are the individual entities in the directory, not users.
How you accomplish this task exactly depends on how you intend to use it. If all you want is to get the keys into the directory, it would suffice to add the 18.104.22.168.4.1.3401.8.2.11 (pgpKey) attribute to your directory and then add it in your schema as an optional attribute for your user class.
If you want to use this information with GPG (as a keyserver), the problem becomes slightly harder. You can add the schema as it is, and store the PGP keys in parallel with your other data. This would be easiest to set up, but harder to manage in the long run. You can also try to make a hybrid schema, but that will require substantial planning that is really too broad in scope to detail here. However, things to look at would be how you want the keys to be written (who has write permission? Perhaps just administrators?), and which attributes the key should be searchable by. Most probably you will be able to add the PGP key attributes
pgpCertID $ pgpKey $ pgpDisabled $ pgpKeyID $ pgpKeyType $ pgpUserID $ pgpKeyCreateTime $ pgpSignerID $ pgpRevoked $ pgpSubKeyID $ pgpKeySize $ pgpKeyExpireTime, making them mandatory or optional as you require, to your user object. If the LDAP query GPG uses happens to check
objectClass=pgpKeyInfo however, this might prove difficult and you might have to use a sub-object on your users.
That said, I'd advise you to not do this, and instead set up a separate LDAP keyserver with just the keys in it, at
keys.example.net where example.net is your domain. This will be much more supported and will prevent keyserver load from impacting your general directory performance.