A vertex only attached to a single bone. (so no weighting at all) - not even sure this would make sense.

Weighting to a single bone is exactly how some early engines implemented skinned mesh animation. It greatly simplifies the vertex processing.

what would be a sensible range of values for weights, would the 256 values in a single byte be enough to give smooth animation or would you expect a larger range?

256 different values, converted to a floating point by dividing by 256, would be more than enough resolution for weighting factors. It's not unusual for a vertex to have just 1 or 2 influence bones. So weighting factors, in that case, could be 1.0, ( 0.5 / 0.5 ), ( 0.667 / 0.33 ), etc.. If models are designed for a specific application, I could see having a set of fixed weighting factors of 1, 0.5, 0. 66, 0.33, 0.25 and 0.167 - various values with which 3 or 4 influences could be conveniently arranged. Smooth animations don't require more than 4 influence bones, in any case. Bone weights should always sum to 1.0, so, IF the weights are specified in bytes, you may be looking for a sequence of, say, 4 bytes which sum to 256.Four bone weights for a vertex would then be byte1 / 256.0, byte2 / 256.0, etc.

Note: the bone weights for a single vertex may not in one place. It depends on the data arranglement in the model file. See below.

I'm now trying to discover how bone-id's and weights are set on vertices ... how many different approaches are used to capture this sort of data.

From your description, it's not clear whether your concern is extracting skinning information from model files, or determine how that data is actually used in a particular game. Can you clarify?

That is, how vertices, influence bones, and weighting factors are represented in model files may have nothing to do with how that data is arranged/used for rendering. Several model file formats specify a skeletal hierarchy, listing influenced vertices, and the weight by frame/bone/node. When loaded, the data is then rearranged in the vertex structure you've mentioned - changing it from a list of vertices per bone to a list of bones per vertex.

I've been comparing the different versions of the game (GameCube, PS2 and XBox) and they all seem to have their own version of both the texture and model files

Not surprising. In general, data file format should support quick and convenient loading that normally reflects how the data will be arranged in a particular app or engine. For early games, a lot of work was done on the CPU side of things and import data reflected structures compatible with that way of doing things. Later games, which make use of advances in machine capabilities, likely arrange data files with the same goal (fast, easily formatted loading), but external and internal formats change if, for instance, more work is done by the GPU.

The number of pairs summing to 256 doesn't match the number of vertices, nor are each of the pairs unique ... so it's proving interesting

Figuring out how things like that are done can be quite interesting and educational. E.g., perhaps the engine sets all vertex influences to the root bone or hip bone by default, and only if a vertex is given other weights are the defaults changed. If the modeling style supports that, the data set is smaller and loading slightly faster.