By the time you incorporate some third party solution you could have just written it yourself.
For most if not all environments the screen is just a two dimensional array of pixels. Sometimes palletized sometimes not, but that doesnt matter, you can write yours however you want.
There is tons of free code out there for drawing lines and arcs, etc.
The killer may be fonts but I think you will find that a third party app will chew up all of your memory just doing fonts, you are resource limited so you will want to pre-compute the fonts and just copy the bits.
Make a two dimensional array of data, do all of your work on your favorite host at first, it is trivial to save .bmp files if you want to see what you are drawing, and trivial to turn a series of .bmp files into a video if you want to watch some action.
If you use generic C, and no libc calls (write your own memcpy, memset, etc) this code will run anywhere, on the host for development and on the target.
Fonts are going to be your killer you have to pre-compute them but manage to squeeze that info down into as small as you can, and at runtime extract the data and copy the bits for each letter into the virtual screen as fast as you can.
Or just buy one of the many lcd solutions that do all of this for you and you simply send it commands like draw "Hello World!" at some (x,y) using blue as the foreground and white as the background.
Basically I think the non-os solutions are still going to use too many libraries and be too big for your specific application. 2d arrays of bytes or pixels are trivial to manage yourself. Even if you are writing an application for a desktop platform I would do it this way and at the last minute copy the fully renedered screen update to some os dependent library (allows for maximum portability from one OS or not to another).