Truly parallel sampling is rarely needed. Especially if you can separate the triggering (latching) of a reading in the peripheral from the act of subsequently transferring the latched value over SPI, it is likely you can merely trigger both in quick turn and then read them out in slightly slower turn.
But if you truly need simultaneous reading, then you will need a workaround. The ATmega used in classic Arduinos only has one hardware SPI engine. But you can also implement a software or "bit bang" SPI master using arbitrary digital I/O pins.
Typically this is done with single-bit GPIO operations, but if you place the critical SPI signals for both chips (probably SCLK, the others are usually only sampled at changes in that) on distinct pins of the same GPIO port, then you can use whole port operations at raw AVR level (below the Arduino API level) to drive them at effectively the same time.
To make this work, you would do the following:
1) For each SPI peripheral, figure out exactly at what transition of what part of what access sampling occurs. Make sure to include any internal setup or latency within the chip in the determination.
2) Start the access to whichever peripheral takes longer using port-wide operations which preserve the status of bits not related to this peripheral.
3) Add the access to the peripheral which takes less setup before the sampling instant by starting to include the bits connected to that in the values to be changed in the port wide GPIO operation.
4) Use a similar port-wide operation to trigger the critical sampling operation for both devices at the same time
5) Continue with whatever followup each device needs, and stop updating its pins when no more operations are needed by that device.
Do be aware that some SPI devices, particularly those which are ADC's or having ADC type behavior internally, can be quite sensitive to jitter or timing variation in the clock edges. You may want to look at using an interrupt or even a hardware counter/time or the SPI peripheral to generate the SCLK edges, and operate the other signals with interrupt driven software slaved to that.
Again, in most cases true parallelism will not be needed. But if it is needed methods such as this can achieve it at the cost of intricate software.