I guess also there is no mechanism right now to grow your initial block of memory if it proves inadequate, though this can be easily fixed. Also there is one potential gotcha the way this is written. An important, though not often used compiler optimization is to rip apart structures and classes and treat their individual elements as atomic variables for register allocation and other standard optimizations. It has a name but it escapes me right now.
Such an optimization could potentially nerf your initial allocation of the free list, since you may not be guaranteed that there is head room after the end of your class/structure. I am not sure, but ANSI C, for example, may not necessarily require structs to be held in contiguous memory. Though in this case you are probably safe since it seems to essentially be a recast of a pointer to the larger size pool. C++ is kind of weird though. I'm always surprised at what is really going on under the hood.
For the technique I use, I basically want an allocation to pop the address off of a stack (an array) and return, whilst free pushes the address on to a stack. So which is faster, reading an entry from the top of an array and increment the array pointer, or simply returning the next entry in the linked list. The linked list approach has a slightly smaller instruction count I suppose. However if the stacked is used often it should be in cache memory, possibly reducing memory look up time, although perhaps that's true in your case as well since the data item itself should be contiguous to the next pointer.
Freeing however requires looking up the data structure in the next pointer which may not be in the cache. One can never tell these things until one tries it however. It would be interesting to benchmark it.