Yes and no.
Yes without termination and other signal quality considerations, see above.
With signal quality considerations, you are still limited by the round-trip distance delaying returning data (MISO). Data is set up on one clock edge and sampled on the other, so you have a half cycle limit. Example, at 10MHz, velocity factor 0.67 (regular coax), the limit is 10 meters. (At slower rates, you probably have some more signal quality considerations -- due to losses in the long line. At 100m, you may want a regenerator (buffer) in the middle.)
No with considerations: SPI can be extended arbitrarily, by driving a transmission line (using coax for single-ended transmission, or e.g. RS-422 transmitters and receivers for twisted pair), and inserting a regenerator and synchronizer periodically.
Note that RS-422 can be used seamlessly as a cable signaling standard, with big wins for signal quality. Expect to pick up many volts of interference on a long cable run. RS-422 receivers have over 7V of common mode range, whereas straight logic has hardly a volt of noise immunity.
Hmm, a synchronizer should still incur a cycle delay, lest it imply violating the speed of light. You get a half cycle of allowance built in, but beyond that... Eh, I'd have to draw a diagram to see what's missing.
In any case, whatever delay MISO has at the end, you need to account for that on the receiver. You may want to build a custom receiver (i.e., just a 74HC595) with delayed clock action to recover the data properly. Then you'd be reading data back from a GPIO port, rather than the SPI register. Small change, on most platforms, I think.
As you can see, "possible" isn't necessarily "practical". You're better off with a proper long-distance standard over, say, tens of meters. For embedded stuff, if it doesn't need to go fast, asynchronous serial is fine (particularly over RS-485, very popular in industry). CANbus is great, very reliable (error checking and recovery is baked into the hardware). Ethernet is powerful, though it has a lot of overhead; much of that is provided in hardware on the more powerful MCUs, which have more than enough power to handle the higher level protocols as well.
Tim