I'm very sorry we missed responding to your post sooner!
The first part is what happens when loading skeleton. A SkeletonJson or SkeletonBinary is created and receives an AttachmentLoader (be sure to see that AttachmentLoader link). Often an AtlasAttachmentLoader is used, which finds the texture atlas region for each attachment. However, you may not want to setup your attachments with a texture region at that time. In that case, you'll need to provide your own AttachmentLoader. For example, you could setup some attachments with texture regions and others you'd not setup at all, instead setting them up later. Or maybe you want to setup attachments with texture regions from different atlases.
spine-cocos2dx is based on spine-cpp, where most of the relevant API is located. AtlasAttachmentLoader shows how to setup attachments with a texture region from an atlas:
https://github.com/EsotericSoftware/spine-runtimes/blob/3.8/spine-cpp/spine-cpp/src/spine/AtlasAttachmentLoader.cpp
That sets the rendererObject to an AtlasRegion. Next spine-cocos2dx extends AtlasAttachmentLoader to do a little additional work, replacing the rendererObject with an AttachmentVertices instance:
https://github.com/EsotericSoftware/spine-runtimes/blob/3.8/spine-cocos2dx/src/spine/spine-cocos2dx.cpp#L66-L77
If you omit most of the code from both of those attachment loaders, leaving only the construction and return of the attachment, then loading all the data will be successful, but you'll have attachments with no rendererObject, so you won't be able to render them until the attachment is configured. Search for AttachmentVertices in SkeletonRenderer if you are curious about how it is used for rendering.
So far the above should help with understanding how skeleton data is loaded and attachments configured for rendering. The next part is about how you might want to do what you need. I understand you have many images and don't want to configure them all in Spine. One approach is to configure one attachment in Spine, where it's easy to position it as needed, then at runtime configure it to use a different texture region. As mentioned, that could 1) be done in the AttachmentLoader, or 2) do nothing in the AttachmentLoader and configure it later, any time before it needs to be rendered.
If you want to use an image that is not in a texture atlas, you'll still need to configure the attachment, but a little differently since you won't have an AtlasRegion object. You'll need to do 1) what AtlasAttachmentLoader does to configure the attachment's region* fields (you don't need to set the rendererObject to an AtlasRegion), and 2) set the rendererObject to an AttachmentVertices instance, which is what has a reference to the cocos2dx texture, for that see the setAttachmentVertices in spine-cocos2dx.cpp. Unfortunately I don't have more sample code for cocos2dx that does this. I can at least point you at this related forum post:
Single SkeletonData instance with multiple dynamic atlases
Note attachments are normally shared state across skeleton instances. When you modify an attachment, all skeleton instances will be using that attachment. You may want to make a copy of an attachment and configure that, allowing you to customize each skeleton instance.
Finally, since you mentioned skins in email, so you may want to configure skins at runtime. For that at least we do have a cocos2dx example:
https://github.com/EsotericSoftware/spine-runtimes/blob/3.8/spine-cocos2dx/example/Classes/MixAndMatchExample.cpp#L57
This shows how to create a new, empty skin and add other skins to it. You can also add individual attachments (which may be copies) to the skin.
