From the SPI wiki page:
Note that even if you're not using the SS pin, it must remain set as an output; otherwise, the SPI interface can be put into slave mode, rendering the library inoperative.
I was initially confused about this too until I read the ATmega328 documentation. The important thing is that pin 10 be configured as an output, the value
of it is then ignore by the SPI hardware.
The Atmega documentation says:
If SS is configured as an output, the pin is a general output pin which does not affect the SPI system.
This means you can usefully set it high and low yourself to tell your peripheral that you are about to send data to it (with SPI.transfer). The library doesn't do this for you because it doesn't know for sure which pin you are going to use for the SS pin (you might have multiple peripherals).
As for the 16 or more bits, I don't see what is stopping you sending more than 8 bits before raising SS back to high. For example, this test code appears to "work", at least, connected to a logic analyzer:
const char * test = "Hello world";
const char * p = test;
// commence "transaction"
digitalWrite(SS_PIN, LOW); // this is pin 10 in SPI.h
// send test string
for ( ; c = *p; p++)
// end of transaction
Analysing the Ethernet shield in operation appears to confirm that holding the SS pin low for extended transfers is perfectly normal.
The constructor for the inbuilt SPI library appears to configure all 4 pins in the correct directions, so you shouldn't need to change them yourself, unless you are planning to use a different SS pin (in which case you also need to set that to output).
But as I said above, it appears that the library does not manage the SS pin for you apart from setting pin 10 as an output.