New discovery!
I found out where the game stores the palette pointers for the "Special" sizes.
Once the game determines that the monster is a special size, it looks up a set of five corresponding bytes in a table at 7D000 (FCE00 in LoROM).
Byte 02 determines the palette.
So, for D. Mist (Size 80), the five bytes are at 7D000 and are:
D. Mist uses Palette A1 (Multiply by 10 hex and add to E7000 = E7A10 for the beginning of the palette data).
If I want D. Mist to use Imp's palette instead, I change the data at 7D000 to read:
Of course, D. Mist changes into mist and at that time changes to special size 81, so you'd need to change the A1 at 7D007 to the same thing, unless you want the mist to be a different color than the dragon.
So there you have it. Unfortunately (I guess), the palette must stay linked to the size, but by default, each special size is linked to only one monster (and to change that fact would probably be more work than it was worth anyway).
I'm sure the other four bytes per size in this table do fun things as well, but I haven't experimented yet. I'll keep you posted. 
It seems the other four bytes work together to point to the sprite arrangement.
I don't know why the programmers chose to sprite it the way they did, because these numbers all roll around a bunch then finally end up indicating a two-byte pointer in the table beginning at 75100 (ECF00 in LoROM).
2 The fifth byte in the five byte sequence above indicates which pointer within this table will be used. So, D. Mist's fifth byte is 00 - it will use the first pointer.
Add this pointer to E0000 in LoROM, or 68200 in ROM, to get to... Dat-da-da-daaah the sprite arrangement data!
It doesn't work exactly like it does for summons. Basically, when a monster's image is loaded into the game, the game starts at the pointer and loads a ton of sprites into memory - more than it needs for one image, more on that later.
The game has also, at this point, picked out a size from the table at 7015E, which is larger than we originally thought.
More on that some other time - I have to finish up for the day. The size is determined by the second byte of the info at 7D000, but
only by bits 0-5 of that byte. bits 6-7 have an entirely separate purpose (don't know).
So, using the example of D. Mist again, byte 01 of its entry in the table is 91 (10010001). Ignoring bits 6-7 (for the moment), we get 11 (--010001). This tells us that D. Mist uses the 11th (hex) size in the table (0Ax08). If we wanted D. Mist to be 2x2 instead, we can change this to 00 (the first entry in the size table). Just be sure to leave bytes 6-7 the same. So to make D. Mist 2x2, change the 91 at 7D001 to 80.
So, we've got a defined x and y size from the size table, all the game needs is to know how to fill that space. In the case of D. Mist, the data (at 75172) reads:
-- -- FE 06 00 01 02 FE 06 03 04 05 06 FE 03 07
08 09 0A 0B 0C 0D FE 03 0E 0F 10 11 12 FF 14 FE
03 15 16 17 18 19 FE 05 13 1A 1B 1C 1D 1E 1F FE
02 20 21 22 23 24 25 26 FF 27 2F 2A 2B 29 2A 2B 2C 2D 2EFE represents a number of blank spaces, defined by the following byte, so D. Mist's image starts out with six blank spaces, then the arrangement data tells the game which of the stored sprites to display - so sprites 00, 01 and 02. Then there are 6 more empty spaces. Now, on the first line, as defined by D. Mist's size, there is only room for one more space (D. Mist's size is 0Ax08), then we go to the next line for the other five empty spaces. Then sprites 03, 04, 05 and 06, then three more empty spaces... and so on in that fashion. FF represents a single empty space (a space saver for when you only need one).
Like I said, I have to go for today, but I wanted to get this all down while it's still fresh. I'll elaborate/clarify later or tomorrow when I have more time.
