I2C Communication Speed across Sensors
\$I^2C\$ is a clocked serial protocol, which in general means that there is very little which limits the speed electrically.  Most \$I^2C\$ busses run at 100kHz or 400kHz, which will far outstrip most IMUs' ability to output data.

For example, I was on a robotics team which used a Memsense nIMU and if you look at the datasheet, it says that the bandwidth is 50Hz, and it outputs 34 bytes in a packet.  This means that you could theoretically pull up to \$50*34*8=13,600\$ bits per second or 13.6 Kbps.  The chip we ran with could run up to 400kHz so it could handle quite a few of these on the bus at maximum data throughput.

Looking at the datasheet for the atmega128 you provided, it says the "TWI" or two-wire interface is limited to 400kHz.  Knowing the \$I^2C\$ protocol, this will be 2 clocks for the start condition, 1 clock for the stop condition, and 9 clocks for the address, and 9 clocks per byte.  So using the nIMU I referenced before, this gives a virtual \$34_{bytes}*9_{clocks per byte}+9_{address clocks}+2_{startbit}+1_{stopbit}=318\$ clocks per packet.  This means that there was no limit on the sampling rate, we could read \${400,000/318}=1257\$ packets per second.  Since we're limited by the sampling to 50 packets per second, we could instead have 25 IMUs sending out data.

Looking at the ITG datasheet, you'll need to do some math to calculate exactly the maximum sampling rate, but I think 125Hz looks like a good baseline (see section 8.2).  It outputs 3, 16 bit numbers giving 48 bits per sample.  \$48*125=6,000\$ bits per second.  Well within range of the 400kHz you has access too.  With the adxl345 it looks like the maximum data output rate is 3,200 bits per second (I think?).

So from the looks of it, the combined maximum throughput of the two devices you've picked is 9,200 bits per second, and the atmega128 has a throughput of ~400,000 bits per second.  I don't think you need to worry about the ability of \$I^2C\$ bogging down the system.