Given that the conversational state of the bean is passivated and the bean evicted from memory to conserve resources, if the client calls a method on the passivated bean instance, how does the container pick up the correct conversational state for the client.
How does the EJBObject help in this, if at all?

This all works due to the fact that the client never talks to a bean itself, but goes through the container.

When you call myRemote.doIt() you are really talking to the container. If the bean is activated then it can just call a method on that bean (after doing any security/TX checks).
If the bean is not in memory, the container can look to disk, load up the bean if it is passivated, and then call the method on the bean.

So, its all due to the fact that you get access to the bean via the traffic cop, that it can do anything it wants behind the scenes, just like an operating system and virtual RAM.

That's very well taken, but could you please explain the exact mechanism of what goes on behind the scenes as you rightly pointed out.