I think there are few examples because of lack of motivation.
Normally when you implement a compiler or an interpreter the point is raising the level of abstraction. It makes a lot of sense to implement an assembler writing in machine code, then a C compiler using the assembler, then a Python interpreter using the C compiler...
Staying on the same level or going in the opposite direction is not nonsense but a lot less natural... and is done mainly for portability. Some cases are implementing an assembler (for a different processor or for a generic processor) using an higher level language, bootstrapping a compiler, implementing a virtual machine.
With Lisp the whole idea of language level doesn't fit that well (here I mean a full Lisp that includes general full macros, reader macros and that is not allergic to side effects, not a self limited version that only allows template based macros or forces you to a functional programming model).
Lisp is neither an high level language, nor a low level one... more than a language Lisp is a meta-language in which you shape the language that would be ideal to solve the problem you are facing. Creating language abstraction levels is just normal programming in Lisp and doesn't require a new language, compiler or interpreter.
In Lisp you don't need to implement a whole different language if you need a specific abstraction (e.g. exceptions, objects), you just implement that abstraction for use within Lisp. There have been systems programmed down from hardware control up to artificial intelligence all in Lisp.
For example in Common Lisp there is support for object oriented programming (and more sophisticated than in C++) but if it wasn't there it could be just coded... and indeed it was a regular library before Common Lisp. In C instead the only way was to create a full compiler from C++ to C to be able to get there.