ConTeXt does have switchable backends built into its architecture, but the backend you want doesn't exist yet. There is an XML backend, whose output you may want to plug into an XML-to-text converter; or you may want to write your own backend. Either way, I don't know enough to help you any further.
If you want to know more about writing backends, send an e-mail to the mailing list at
firstname.lastname@example.org. The developers actively participate there, and your question is sure to interest them. At least you should be able to discover if it's within your abilities.
Oh, and like Joseph Wright says, you'll need to think about your requirements. Do you want paginated output? How will you handle footnotes and cross-references? Where do floats go? What about paragraphs in table cells? In short: how many features do you want to translate?
Answer ends above; below are some facts about backends
ConTeXt keeps it backends in
back-*.*. Current files:
back-ini.mkiv, back-ini.lua # Initialization
back-exp.mkiv, back-exp.lua # XML export
back-pdf.mkiv, back-pdf.lua # PDF
back-swf.mkiv # Shockwave experiment (for *inclusion* in PDFs?)
back-u3d.mkiv # U3D experiment (3D graphics) (for inclusion?)
From the start of
Right from the start ConTeXt had a backend system based on runtime pluggable code. As most backend issues involved specials and since postprocessors had not that much in common, we ended up with a system where we could switch backend as well as output code for multiple backends at the same time.
Because LuaTeX has the backend built in, and since some backend issues have been moved to the frontend I decided to provide new backend code for MkIV, starting with what was actually used.
At this moment
.dvi is no longer used for advanced document output and we therefore dropped support for this format. Future versions might support more backends again, but this has a low priority.
The big question is: what is to be considered a backend issue and what not. For the moment we treat image inclusion, object reuse, position tracking and color as frontend issues, if only because we deal with them via Lua code and as such we don't depend too much on macro calls that need to inject code for the backend.