I suppose the actual design of such a struct would be close to Waker/RawWaker? It'd be unsafe to construct but there is a public representation, and the use should be safe. It's not quite obvious how to do all of this in a user-defined crate outside of std if one wants to potentially make use of the vtable-hacks for a performant integration with trait impls.
That's not quite true. With regards to allocated data structures there are a lot of paper cuts that the standard libraries' containers solve by virtue of being integrated with the compiler and using unstable features. For example, coercion of Box<T> -> Box<dyn Trait>, as well as a couple of const methods, and the #[may_dangle] attribute. I suppose a fully custom alloc, independent of its GlobalAlloc but with functionality comparable to it, is slowly getting possible but currently you have to be quite inventive to work around restrictions. Plus, you need to duplicate a fair amount of code for the actual data structures.
In other regards, without-alloc tries to do something similar but actual integration with non-global allocators was halted on said paper cuts and the unclear direction of the allocator traits.
Still, I consider this path easier than retrofitting full allocator customization into std and there are a lot of lessons we can learn from the manner in which this was done in C++.