Well, you have to get the geometry on the screen somehow, so you'll have to do some sort of re-render. What you could do is only render a portion of each side so that there are no repeats in rendered geometry, if that increases your perception of the efficiency.

If there is some pixel shader that can do this in a single render, then pardon my noobness.

Suppose the player is at some random point on your map. Imagine tiling your map so that theres tiles all around the current tile. Like this:

* - * - *
|...|...|
* - * - *
|...|...|
* - * - *

Each star is a tile, with the tile the player is in in the center. Each quad in the tile would be rendered 9 times then. One of those quads is closest to the player. Only draw that one (occlude the rest, or don't even send it to the hardware).

Repeat for all the quads in your map. Obviously you don't want to actually test every quad like this, but if you segment your map into zones, and test the zones, this should be really easy. Instead of throwing your geometry up as a single object, throw it up as, say, 100 objects or pieces. (Quad trees would work too, it depends on your needs).

Dynamically move the pieces as the player moves, determining where the object can be placed that is closest to the player. You'd only ever be drawing your map once; there wouldn't be any redundant rendering calls.

This would still cause oddities if your view distance is greater than your map length. Starfox had very thick fog for this sort of thing for this reason, among others, I think.