I think it's best to answer this question by giving some insight into how things work a little lower down. First a caveat though: I'm not a firmware expert by any stretch of the imagination; my rather rough understanding of how the Pi camera module works is based on my experience of writing the picamera library and interacting with the much more knowledgeable firmware developers on the Pi forums. If you hear contradictory information from the firmware devs, they're the authority on this, not me! With that out of the way...
As soon as the Pi's camera module is initialized it is capturing frames. These frames are (as far as the end user is concerned) dumped but inside the camera's firmware there's a lot more going on. The frames are measured to determine the gain to apply to the sensor (AGC), the white-balance to feed to the AWB correction algorithm, etc. For example, if you start up the camera and immediately start recording you'll typically see the white-balance correct itself over the first few frames of the recording:
import picamera
import time
with picamera.PiCamera() as camera:
camera.resolution = (1280, 720)
camera.start_recording('video1.h264')
time.sleep(5)
camera.stop_recording()
However, if you place a delay before you start recording you'll see that the white-balance is stable by the time the recording starts:
import picamera
import time
with picamera.PiCamera() as camera:
camera.resolution = (1280, 720)
time.sleep(5)
camera.start_recording('video2.h264')
time.sleep(5)
camera.stop_recording()
So, given that the camera is always capturing frames even when we're not capturing images or recording videos, what actually happens when we elect to capture an image? We tell the firmware to activate capture, and the firmware waits for the next frame to complete before passing it back to us (actually, if you're capturing images from the still port instead of the video port there's a lot more that goes on including mode switches, but you're concerned with the video port so let's ignore that).
Consider what this means for synchronization (your particular use case). The camera isn't "ready" to capture a frame at any particular point. It's already capturing a frame and when you ask for one it'll hand you the next complete one that becomes available. In order to synchronize the cameras' frames all the cameras would have to be initialized at exactly the same time, and then their internal clocks would have to run precisely in sync (the cameras have their own internal clock; they don't rely on the Pi's clock).
Sadly, I don't think this really is a realistic prospect. If I recall correctly, the Pi compute module (which has 2 camera ports on-board and supports 2 camera modules simultaneously) uses some special calls in the firmware to get the 2 modules to use a single clock signal (I have no idea how this works at the hardware level but I assume it's using something specific to the compute module); I can't imagine how you'd do something similar across 4 Pis.
Update:
I should add that it is possible to do rough synchronization with some reasonable networking knowledge (e.g. UDP broadcast packets). In other words, it's possible to get all Pi's on a network to trigger a capture within a millisecond of each other (assuming a decent low latency network like Ethernet), but as described above that still won't guarantee that all the cameras will actually capture a frame at the same time; there'll be up to a frame's worth of lag (plus network latency) between the start times of the resulting captures.
If that level of synchronization is enough for people, they may want to check out the compoundpi project which is another project I wrote on top of picamera for just this purpose.
