Don't abbreviate unnecessarily

Most of the names you've chosen for variables and functions look fine to me, but there are some weird, unnecessary abbreviations:

• resiz -> just write resize
• alloc_sz -> I would write alloc_size or size

Some abbreviations are quite commonly used so I'd keep those (like Elems and alloc instead of Elements and allocation). However, be consistent: why is it nElems but m_MaxElements?

Create a class chunk

Your pool consists of multiple chunks, and each chunk is an array of nodes. It makes sense to make a proper type for chunks as well. While you are at it, avoid doing manual memory allocations, and let std::vector do it for you. The alloc_chunk() function can become the constructor of chunk.

struct chunk { std::vector<node> nodes; chunk(size_t nElems): nodes(nElems) { for (auto &node: nodes) node.next = &node + 1; nodes.back().next = nullptr; } }; 

But this also leads me to:

Consider using a std::deque to store nodes

Your allocator requires each node, once allocated, to be at the same place in memory for the rest of its life. If you resize a std::vector or use realloc(), the storage might be moved. This is why you are using chunks. However, there is a STL container that gives you stable pointers and the ability to resize: std::deque. This allows you to get rid of chunks.

template <typename T> class pool { struct node {/* same as before */}; std::deque<node> m_Nodes; node *m_Head{}; public: pool(pool const&) = delete; pool& operator=(pool const&) = delete; pool() = default; pool(pool&& o) = default; ... T *alloc() { if (!m_Head) { m_Nodes.emplace_back({}); m_Head = &m_Nodes.back(); } ... } ... }; 

Performance

Your allocator is very good when storing large objects and when the game doesn't need to allocate large batches of objects at a time. However, it has the overhead of one pointer per element, so if you are storing small objects, you might be wasting a lot of memory. Furthermore, there is no better way to allocate a batch of objects than to allocate them one by one.

If you want to store small objects (for example, struct message is not that big), then instead of having a linked list of free nodes, it might be better to use (a tree of) bitmaps to store which elements of the chunk are used or not. Finding a region of consecutive free elements might also be much easier this way.