Unless your I2C hardware components have the ability to use an external clock to drive the clock line of the buses (none that I've heard of), you wouldn't be able to do this by hardware.
You could do this by manually driving the buses. This is called bit-banging. If you do that, you can carefully craft your software driving GPIO pins that act as I2C buses and manage all 8 buses in parallel. You would most likely want to do the bit banging by interrupts.
You can have your piece of software having 8 (global) variables (of a
struct) that tell if and what needs to be written to each I2C and if and how much needs to be read as response. Regardless of hardware I2C or software-emulated, this step is actually necessary anyway.
In your bit-banging piece of software, here are some things to look out for:
Of course, this is to make 8 parallel unrelated I2C buses. If your application needs to talk with 8 of the same kind of device, then your bit-banging software would be simpler, since they all start and stop at the same time, even if their data and ACKs are managed separately.
Note that the I2C emulation software is not replicated per thread, but is one managing all of them at the same time.
While I'm always up for using the hardware in ways beyond most people's wildest imagination to get it to do something better or faster, I'd advise you to study your problem a bit more, do some calculations to make sure you actually want to do this.
Emulating hardware through software is very error-prone and slower by an order, there are very many edge cases and needs thorough testing. In short, it's a time-consuming job. Being slower than hardware also means that there is a point where it starts to become beneficial and you need to find that point. Since you have 8 devices and 2 I2C hardware components, you can attach 4 devices to each bus and you need to study if your implementation would actually be faster than that.
You may also think of changing your hardware. A Cypress PSoC for example lets you put as many components as you want (and there is space and resources on the chip) so for example you could put 4 I2C buses (if 8 wasn't possible) and attach 2 devices to each bus. With a PSoC and knowledge in verilog, you can also write your own 8-device I2C bus component implemented in hardware.
Alternatively, you could also think of changing your bus. I2C is a very strict protocol designed to ensure error handling with each byte as well as prevent component cross-talk. You might not need that much restriction and for example you could check the data with CRC so you may not care for intermediate errors.
You could use an SPI bus, which is much simpler and thus easier to emulate. As a bonus, you don't need to be working with an open-drain data bus (as in I2C) which means you can get to speeds that are much higher than I2C. Common support for I2C buses go up to 400Kbps (newer ones go higher) but common devices supporting SPI bus can easily go up to 4Mbps.
That said, talking serially to 8 devices on an SPI bus @4Mbps could indeed be faster than talking to 8 devices in parallel on I2C buses @400Kbps (depending on the protocol). Again, this is something you would need to assess to see which option is more beneficial to you.