The problem I see with stating the consequence for INVISIBLE is that the consequence might change in the future. For example, unless I'm mistaken, if you made Block.DIRT invisible, Block.getColors() would still work. Block.getColors() failing has nothing to do with the INVISIBLE property, but rather whether or not Block.getColors() has logic for the given block.

    // INVISIBLE causes a block to be ignored by the renderer.
    Block.INVISIBLE = 0x1

For the Block.SOLID, you're probably right in including some description of the consequence.

    // SOLID causes a block to be considered by the physics engine as
    // a collision candidate.
    // This means players will not be able to pass through the block.
    Block.SOLID = 0x2

Also, we should probably define SOLID by it's inverse GAS or something, since we want blocks to be solid unless specifically defined otherwise.

Also, this whole BLOCK_PROPERTIES bitfield is probably way over-engineered, and should really just be

   Block.isSolid = function () { return this.type !== Block.AIR }
   Block.isInvisible = function () { return this.type === Block.AIR }

(at least for now)