Most probably you don't want to render individual tiles, but a mesh of quads, like a grid, where those inner vertices are shared by the six adjacent triangles of the touching quads. Since the vertices are shared, there's no risk of them diverging to great gaps. You can assign texture coordinates per triangle instead of per-vertex to give each quad a different tile; animation can be achieved by updating those coordinates each frame. Destruction can be achieved by re-assigning those coordinates to an empty/transparent tile, or damaged tile -- Debris and such would be drawn separately.

Drawing the ships to a 2D render target and then drawing that to the screen in one go is also viable, but remember that you have to animate it and change tile images there -- and the most complex part of drawing this large ship with potentially-high zoom factors will be to determine the sub-section of the ship that you need to render to that 2D render target -- then transforming it a bit differently because you no longer have a fixed origin. I guess 64x64 tile ships at 64x64 pixel tiles is 4096x4096 pixels, and modern GPUs should be able to handle textures that size, but its still a 90MB texture per-ship assuming 32bit color and mip-mapping -- You're approaching 1GB of texture memory with only 8 ships, and that's not an uncommon amount of memory on a low/mid-tier GPU from recent years (in fact, the Steam hardware survey says that just over 1/3rd of their users have 1GB or less VRAM).

A good search term is PTEX (Per-face TEXture mapping).

However, I spoke without my coffee this morning, and if you're pretty green with 3D its more straight-forward to just duplicate the vertices -- as long as the vertices are identical going in, and as long as they always get transformed by the exact same matrix (if you regenerate it, you have to build it by composing the component matrices in the same order), then the vertices won't diverge, and the filling rules ought to prevent pixels from fighting in a steady scene -- you might perceive some fighting as the ship rotates though -- MSAA/FSAA should help smooth that out.

On a separate note, if your very large ships become very small on-screen (say, where a tile occupies maybe < 4x4 pixels, you might then want to switch to rendering it as a single textured quad that's generated via means similar to the 2D render target method; once you can't see the detail in the tiles anyways, its a lot of work to go through for no real benefit, and rendering very small triangles is a huge performance drain. I would choose the transition point to be where the animation of the tiles gets lost in the smallness of them on-screen, then you don't have to worry about animating this small ship texture.

I assumed this whole time that you're rendering moving things like crewmembers separately, so you'd do the same for them when the ship takes only a small portion of the screen (assuming the position of crew members has meaning to the player when zoomed out this far), so you could transition them at some point to being rendered as single pixels. Likewise, you could do the same for an important indicators that would normally be shown with a tile animation.