The 7-pin display modules do not need "just" SPI, but also CS (Chip Select), D/C (Data or Command), Reset, and optionally a PWM pin for controlling the backlight. As KurtE mentioned, this should work in theory, but the problem is existing library support. The CS pins need to be separate, but all can share the D/C and Reset pins (although you cannot then reset just one display; you can only reset them all if you need to). There is always the risk that the display modules don't like sharing their lines among so many modules -- for example, if there are too many pull-up/down resistors in the lines, or even if the modules don't like their D/C pins toggled when their CS is not selected.
The existing ST7735 libraries I looked at do not use a canvas, but send the pixel data resulting from drawing commands via SPI. Assuming 16-bit RGB color, each 128×128 frame needs 32768 bytes; 128×160 needs 40960 bytes. With a full canvas, it would be much easier to support the eight SPI displays, because then the SPI transfers could use DMA. If the library is the only one using that SPI bus, you could avoid the CS pin restrictions by reserving the hardware CS pin (i.e., keep it unused), and let the SPI library think it is using hardware CS pins, too.
The leftover issues is that I don't know of any graphics libraries for the 16-bit color canvas; you'd need to write your own. The easiest would be to just read them from raw binary files from a microSD card using Paul's SD library. (It is trivial to convert to/from that raw hardware format and e.g. NetPBM binary .ppm format; and NetPBM tools contain converters to/from JPEG, GIF, and PNG.) Still, you'd need some kind of font-drawing (overlaying on top of image read from microSD) at least. So, quite a bit of coding work.
Another option is to use "intelligent" display modules.
There is at least
one seller on eBay with RGB TFT display modules (of various sizes) that support I2c. These have some sort of microcontroller on board, and you can set different I2C addresses for each module, so you should be able to control several of these on the same I2C bus (without the I2C multiplexer). Instead of pixel data, you send the drawing or writing commands as text to the desired module, so no library per se is needed. They also cost about three or four times as much as the above 7-pin display modules.
Personally, I might use slightly smaller, single-color (white) OLED modules.
There are up to 1.3" single-color OLED displays using the SSD1306 controller. I have the white ones, and I like them quite a bit. Make sure you look at the four-pin ones. In the yellow/blue models, the pixels near the top are yellow, and the rest are blue, on a black background. So, each pixel is always the same color if lit: monochrome. The larger ones (0.96" and 1.3") are 128×64, the smaller (0.91") are 128×32.
Use eight identical I2C displays, and an I2C multiplexer like
Adafruit sells (or a cheap eBay clone). You only need minimal changes to the
Adafruit SSD1306 library, to fully support the I2C multiplexer. This is because the library only communicates with the display at init and display times. At init time, all displays need to be initialized (a new constructor function, that takes the heights of the up to eight displays into account, and drops the splash). A new variant of the .display() method takes an additional parameter, to choose the display to be updated with the current canvas; you can even update the same canvas to multiple displays. You can also add helpers so that the canvas is easy to load from a 1024- or 512-byte (128×64 or 128×32 bit) raw binary file on a microSD card (say, using Paul's SD library), in case you want to display nice pre-drawn icons, and optionally add text/lines/bars on top. Drawing/writing text to the canvas is done using
Adafruit GFX library. There is only one canvas, but you can send it to any display or displays. (You can obviously also keep the icons in Flash, but there isn't that much room there.)
I could probably provide the changes, porting it to the i2c_t3 library (using DMA for the i2c transfers), but I don't yet have a multiplexer to test the code, and my newest Teensy is a 3.2. The changes are really simple.
Note that SSD1351-based 1.5" RGB OLED displays do not support I2C; they have a 3-wire SPI mode, not I2C. Beware of erroneous listings!