This has been tried; the big idea of xhtml+xsl was that your server would answer any request with an xml api response and some xslt that transformed it into a webpage. Now admittedly part of the reason that failed is that xslt is a pile of crap, but even if it hadn't been the aproach is wholly unsuitable for building modern, responsive UIs. The behavior you want from an API - consistency, separation of concerns -is completely at odds with what you want on a page, and there are a whole lot of concerns you want to hande server-side (e.g. pagination) but that don't make sense for APIs. It's not that no-one's thought of this, it's that the current approach, where you have a thin but distinct server-side presentation layer (or even client-side javascript - the point is that you need a full-eatured program to turn go from API calls to good UI), works better in practice.
That works (though you might have trouble with older browsers), but you need to treat it as a "real" program, and you wouldn't want to serve it from the same endpoint as your API using accept headers like you're suggesting. And it's not really any different from the current way of doing things; it's always been good practice to build your web tier on top of your API.
