Thanks Roedy. I actually figured it out. The red, green, and blue are
still kept in separate int's.

I thought too from the description that they would just take up two
int's, one to holder the upper bounds of the ushort and one to hold the
lower bounds.

It ends up that each separate bit value needs to be saved off in its own
int. That's why the size was throwing me off. It ended up working like:

int[] pixelData = new int[(int)(rawData * 1.5)]; // 2 bytes into three ints
int pixel = 0;

for (int i = 0; i < pixelData.length; i += 3)
{
    pixel = [two bytes into an int];

    pixelData[i] = [red masked portion from pixel];
    pixelData[i+1] = [green masked portion from pixel];
    pixelData[i+2] = [blue portion from pixel];
}

It ended up having much poorer performance than using an ARGB type. I
think because on rendering it had to do the conversion to full RGB. I
ended up going back to storing my data in ARGB format and doing the
calculations before calling setPixels to convert the 5 or 6 bit values
to its correct 0-255 range. It seems like more work up front but then
better performance by the rendering engine later on.