Is it valid to use bit-depth to determine the size of the colour table in a BMP image?

Let's look at the Windows Metafile Format which defines the BMP format. I checked both v11.0 from 2013 and the latest v17.0. In particular, you seem to be interested in the DIB header of kind BITMAPINFOHEADER (of size 0x28 bytes, described in section 2.2.2.3). The BITMAPCOREHEADER (most primitive kind of BIP header) only specifies the color bit depth, and other versions of the header are either proprietary extensions (BITMAPV2INFOHEADER, BITMAPV3INFOHEADER, OS22XBITMAPHEADER, etc) or extensions which just add more fields (BITMAPV4HEADER, BITMAPV5HEADER).

The two fields we are interested in are BitCount (offset 0x1C, what you refer to as BitDepth) and ColorUsed (offset 0x2E), defined as follows:

BitCount (2 bytes): A 16-bit unsigned integer that defines the number of bits that define each pixel and the maximum number of colors in the DIB. This value MUST be in the BitCount Enumeration (section 2.1.1.3)

[...]

ColorUsed (4 bytes): A 32-bit unsigned integer that specifies the number of indexes in the color table used by the DIB, as follows:

• If this value is zero, the DIB uses the maximum number of colors that correspond to the BitCount value.
• If this value is nonzero and the BitCount value is less than 16, this value specifies the number of colors used by the DIB.
• If this value is nonzero and the BitCount value is 16 or greater, this value specifies the size of the color table used to optimize performance of the system palette.

Note: If this value is nonzero and greater than the maximum possible size of the color table based on the BitCount value, the maximum color table size SHOULD be assumed.

Just from here, it should be clear that in general it is not enough to only consider BitCount to determine the size of the color table.

To elaborate a bit more, the only valid values for BitCount are:

typedef enum {
    BI_BITCOUNT_0 = 0x0000,
    BI_BITCOUNT_1 = 0x0001,
    BI_BITCOUNT_2 = 0x0004,
    BI_BITCOUNT_3 = 0x0008,
    BI_BITCOUNT_4 = 0x0010,
    BI_BITCOUNT_5 = 0x0018,
    BI_BITCOUNT_6 = 0x0020
} BitCount;

Now for the actual size of the color table you will need to refer to section 2.1.1.3 of the document, which describes the above values one by one in detail, explaining for each case if a color table is needed, what size it should be, how to interpret it, and so on.

I'm not going to quote the entire section of the document as it's quite long and freely available to examine, but here's a summary:

• BitCount is BI_BITCOUNT_0: no color table.

• BitCount is BI_BITCOUNT_1 or BI_BITCOUNT_2 or BI_BITCOUNT_3: color table size is 1 << BitCount

• BitCount is BI_BITCOUNT_4 or BI_BITCOUNT_5 or BI_BITCOUNT_6:

  • ColorUsed == 0: color table size is 1 << BitCount
  • ColorUsed != 0: color table size is min(ColorUsed, 1 << BitCount)

In conclusion...

Everything seems to be working fine, but are there unseen consequences of doing this?

Yes, there are caveats, simply doing 1 << BitCount is not enough, you should follow the spec (duh!).

Additionally, is it normal to omit the number of colour map entries?

Not sure whether it is "normal" or "common" form famous BMP implementations to do so, but it is surely legal as per the specification. Note: by "omit" here I assume you mean setting ColorUsed to 0, unless you are working with a different kind of DIB header that does not have a ColorUsed field.