Yes this is possible. The driver doesn't really care what the video format is, since it's job is to tell the SGDMA what to do. The only change that might be necessary is to tell it how long the frame buffer is since 16 bit colour will be half of what is used in the NEEK designs (I forget since it's been a long time since I looked at that code)
You would also need to change the video pipeline hardware so that the colour symbols are padded up to 8 bits/colour if you want to re-use some of the components. If you open the verilog files for each component of the video pipeline you'll notice they are relatively simple blocks so this padding should be easy. For example there is one block that takes the alpha channel and drops it so you wouldn't want to use that since you'll be packing two pixels into a 32 bit word. I recommend using this:
SGDMA --> 'custom format converter' --> Data format converter (56 bit to 8 bit) --> LCD controller
The 'custom format converter' would take two 565 pixels, pad it up to two 888 pixels (56 bits of data). It would also take the pixels and re-arrange them to match what the LCD expects for colour ordering. The data format converter can take these 6 symbols (2 pixels) and shoot them sequentially into the LCD controller. This shouldn't take long to implement the custom logic since it's juse wires moving bits around. I have explained this assuming the SGDMA is fetching 32 bit data, if it's 64 bit then the custom format converter input needs to be wider.
These might contain some helpful information:
http://www.altera.com/literature/tt/tt_nios2_system_architect.pdf http://www.altera.com/literature/ds/ds_nios2_3c25_lcd.pdf