This could be considered an animation problem. If a position correction comes back from the server due to an attempt to move into an invisible object, send back not only the correction but a flag indicating why the correction was needed. Instead of a player popping backwards, he may do a "woah" kind of reeling backwards animation, making it more believably look like he just ran into something.
In games using this approach, it's not uncommon to remove invisibility (at least momentarily) from anything that was run into. Among other things this gives incentive for invisible players to avoid crowds or getting too close to other characters, reducing the frequency that collision with an invisible player happens in the first place. Thus even if your animation for this kind of collision is weak (or non-existent), it's somewhat hidden by the invisible character popping into visibility and clearly telegraphing to everyone what just happened.
The animation need could be removed by not letting invisibility work at close range. This gives even more incentive to invisible players to avoid getting close to other characters. This is a common approach for stealth-based games and AI (replace "invisible" with "not visible to target") and can be seen in PvP games like World of Tanks. There's no need to worry about collision response with invisible characters if you nothing invisible is ever close enough to you to collide with (within latency limits).
Dracor's solution to just ignore collisions with invisible objects is also a good one. This does again require some animations (for the invisible players' client) so objects aren't just clipping through the player's avatar on his screen. If nothing else you can cause visible objects to always push invisible ones so that the invisible player is automatically moved out of the way on the server if someone collides with him.
Invisible-invisible collisions are a bit trickier. It may be advantageous to just disable collisions on them since nobody can see if two invisible objects are clipping together (assuming by "invisible" we mean that both objects aren't visible to the same client). If one of the objects becomes visible it automatically reverts to the visible-invisible collision response (push away the invisible object).
This all gets trickier if invisibility has complicated sets of who can see whom. The first or second solution above is likely best here if you need it. Not every problem like this needs a technical solution; many just need design solutions (e.g., don't allow this feature to your designers).
