An example of binary models I've worked with in the past is the MD2 model format, used originally by Quake 2. The "header" section for all of the models would start with 4 bytes, which is a single int, and as 4 characters was "IDP2". ID and '2' make sense, but I don't know what the P was for. Then the next 4 bytes must be an integer value '8'. This supposedly is the MD2 version, but I don't think it was ever used for anything. Then, other parts of the header are things like the number of frames, uvs, vertices, etc... Also included are offsets, that say how far to move the "file cursor" to get to certain things in the file.
I've also worked a bit with the OBJ file format. It is a text format, but you can learn something from it, which could apply to binary formats. Instead of having offsets to "chunks", each line simply has a one or two letter intro that says what the line is. So 'v' is vertex, 'vt' is uv coordinate, and 'vn' is a normal. These things are basically a list of vertices, etc... and then you have a list of faces, which index into that list, so a triangle could be 5/4/1, 6/2/3, 4/1/2, which means that the vertex positions would be the 5th, 6th, and 4th vertex in the list('v'), and then the uvs would be the 4th, 2nd, 1st set in the list(vt), and then the normals would be 1st, 3rd, 2nd, in the list(vn). Then this would be the manner you would construct the list.
I have also created a bit of software for GameMaker, which converts a series of OBJ files into my own binary format. The "header" simply says how many frames the file has, and how many faces there are in each one. Instead of storing a series of vertices, I store the faces themselves, so the file may be slightly larger than it has to be, but it is easier to read and convert into data for GameMaker. Instead of using offsets, you simply read the amount of bytes you need, and so each frame follows the previous in the binary file.
The thing to understand about file formats is that they can contain basically whatever you need. You choose whatever you want to be in them, and as long as whoever is doing the reading knows the format, they should be able to read it. Some formats store things based on offsets, while others simply assume that you are going to read through the whole thing, and would do so sequentially and therefore not need offsets.
My honest opinion is that you are likely better off just using a known format, the one that most fits your needs. I'm not saying to blatantly waste space, but in modern PCs a bit of waste in media files won't hurt anything most likely. And you'll save in the long run by saving your time, which could be better spent on actual game design then on creating file formats and exporters.