The AVR TWI can be configured to accept a "general call" transfer, which is essentially an I²C write to address 0. All slaves can have an individual slave address and also respond to address 0 (which can be simply ACK'ing SLA+W, for example).
This can be used to sync the slaves. Send data to all slaves, then send SLA+W to the general call address. All slaves will receive this "command" and can start processing data at more or less the same time.
The AVR TWI will generate an interrupt when a stop or repeated start has been generated on the bus. This can only happen when all slaves have released SCL so you can be sure that all slaves that ACKed SLA+W have also processed the command and released SCL.
With this "protocol" you can not be sure that all 11 slaves ACKed the command.
The timing depends on the other code running on your slaves. If no other interrupt is active, it boils down to interrupt latency, which is a few clock cycles (I'm too lazy to look that up now).
I'm not sure if the following works with the hardware TWI: It might be possible to turn the general call into a read transfer. All slaves return 2 bytes and each slave outputs a zero at an individual position. The wired AND functionality of the I²C bus will result in a combined answer from all slaves. The result could look like
1111 1000 0000 0000. The master can check for all the zeros it expected and act accordingly. It might get complicated from here if you want to add an "abort" function that kicks in if not all slaves did their job. I've only tried this once with bit-banged I²C.
One more thing to try instead of a general call read: Mess with the address mask register. The TWI can be configured to accept a single address, but it can also apply an address mask when checking the address. This can be used to turn a non-zero address into a custom general call address that can be used to read data from all slaves at once.
Working this out sounds like a cool project by itself...
And another edit: I've had a look at the datasheet and I've come to the conclusion that the hardware TWI can't be fooled to accept addresses that way. You can try my first suggestion (just send a general call) or write a bit-banged I²C driver that will do whatever you want. Or try something totally different, like vicatcu's suggestion.