My workflow is trending in that direction. I've historically written in AppleWorks, and I wrote a custom translation tool that converts its terribly broken HTML output into somewhat more regular HTML, and another tool that translates that HTML into some approximation of DocBook XML, based on a set of rules about how to recognize section and chapter breaks that are pretty specific to my books. But that's my legacy path for existing books.
Going forward, my new editing tool is a semi-WYSIWYG DocBook XML editor that I wrote, using WebKit as the rendering engine (with some very critical bug fixes from WebKit bug #
15256).
From there, I use a set of custom Perl scripts to perform various fixups on the XML (e.g. adding magic wrap hint markers after em dashes and en dashes, adding custom hyphenation hints for certain words that I've identified as problematic, etc.)
From there, I use some Perl scripts to translate the DocBook XML subset into EPUB, and DBLaTeX to translate it into PDFs for print, with piles of custom XSL and LaTeX macros.
My EPUB title pages are produced by feeding a tiny fragment of the XML through my PDF process to produce a single-page PDF, then using Inkscape to translate the PDF into SVG.
And, of course, I use epubcheck in my post-processing validation pass.
I'm pretty sure that the only non-free, non-custom software I'm using at this point is kindlegen, for producing the MOBI files from a somewhat modified version of the EPUB.