Yes, that is possible by writting your own AttachmentLoader as Nate explained.

When loading a skeleton .json or .skel file, via SkeletonJson or SkeletonBinary, you provide an AttachmentLoader. By default, you'd use an AtlasAttachmentLoader, which takes a single TextureAtlas. IF the attachment loader is asked by SkeletonJson or SkeletonBinary to return an attachment, the AtlasAttachmentLoader looks up the image for the attachment in the atlas.

If you want that to work for multiple atlases, you can simply implement your own AttachmentLoader. Instead of one atlas, it could take multiple atlases. When asked for an attachment, it would look up the image in all atlases it knows about and return e.g. the first hit.

Yep, it's pretty common to want to load only the images needed. It's quite a bit more complex than just loading the textures though. Any app where loading all the textures can work should just do that.

The next step might be to pack atlas pages (see folder structure) carefully to group images that need to be loaded at once on the same atlas page texture. For example, this might be per level, since you probably don't need to load all textures for all levels at once. You could even duplicate some of the common images on the atlas pages.

Most complex is using individual image files and packing at runtime. It takes some doing: you need to determine which images you need based on things like the character's equipped items, items they can pick up during a level, all animations that will be played and what images they need if they show new attachments, etc. Once you figure out the images you need, you need to download them and assemble them into an atlas. Finally you can configure the attachments with the atlas. None of these steps are particularly difficult, but it's a fair amount of work.

If that's not complex enough for you, to get really fancy you could use SVG instead of images. Everything is the same except you download SVG instead of PNGs, then you rasterize them somehow at the right size (probably based on the user's screen size) and then pack those images into atlas page textures. The benefit is mainly that SVG files are much smaller than PNGs, so you could have 10s or 100s of thousands of images.

To make it harder than that, you could try to render the SVG directly and not use images at all. Instead of setting the attachment renderer object to an atlas page region, you'd set it to the data needed for the SVG. Rendering vector is difficult though. Often only a subset of SVG can be supported, and then you need to handle when you artists inevitable use unsupported features.

What are in your skins? If you don't need to assemble them manually in Spine, you could create a skin at runtime and populate it with attachments. That can save a lot of effort when there are thousands of skins.

Otherwise, have you looked at if 1000+ skins would actually be a problem? You can duplicate skins in the editor to reach a number for testing. Attachments and skins may be smaller in the data than first expected.

Oh, I guess you mean skin textures, sorry. Typically the data is all loaded, as there is rarely a good reason to break a skeleton into multiple data files. The textures don't have to be all loaded though. You can control that using an AttachmentLoader:
http://esotericsoftware.com/spine-loading-skeleton-data#AttachmentLoader

For spine-ts see:
https://github.com/EsotericSoftware/spine-runtimes/blob/master/spine-ts/spine-core/src/AtlasAttachmentLoader.ts#L45
Write your own that doesn't configure the attachments with an atlas region. Later, before rendering your attachments, you'll need to configure the attachments with an atlas region.

This mechanism allows you to choose to only download the textures actually needed, or whatever scheme you like. An advanced solution is to download only the individual images actually needed based on the attachments that are actually visible (or expected to be visible, since animations can change attachment visibility) and pack them into an atlas at runtime. We don't have an example of that for spine-ts, but there are examples in spine-unity for runtime atlas packing.