I've always approached multi-player games with pings and I've never written a socket server interface, so I can only advise with what I know from the world of turn-based gaming...

What appears to be happening is that all your enterFrames are firing and then your data is being processed. There's no way to really stagger it so that enterFrames don't fire all at the same time. You could consider setting a Timer to run very very fast and update all the info incrementally as it comes in, if you need a whole state to change at the same time rather than piece by piece... but the best approach would probably be to put a listener on the socket that modified the MC's only when they needed to be modified.

I almost never use enterFrame listeners because they really deteriorate performance...the only exception is for render loops, and even then I'll shut down the listener as soon as an object is holding still for a moment.

For me, it's really critical to number the states passed back from the server, in case they show up in the wrong order. At that point, I always take the highest (latest) state and run the necessary animation to get the object to the new position. In that way I've even made countdown timers that ping every second and are exact enough on different machines to run out within about 0.1 seconds of each other; the only drawback is that on slow connections that miss a ping, they might "hiccup" slightly to resync themselves. That would be less of a problem with a socket.

I never want to rely on every single piece of server data to send the object hither and yon. Just take the most recent piece of info, divide up the component attributes (x, y, scale, currentFrame, value, whatever...) and then write a class that has override setters for all those attributes that do a subtle tween on each one, rather than jump it directly to a position. I can't say for certain that this will work with your live action game, it might just be too slow or glitchy... but will certainly look a lot smoother and less jumpy than if you are relying on the push, because the character will still be executing the prior tween until the new tween takes its place (remember to always stop() the old tween before re-constructing it in the setter)...

Not sure if this will help, but maybe it'll give you a useful view from the slow side...