Indeed, such fixtures are not a good way to run unit tests. The goal of unit tests is to test a very specific (and often very small) part of the code in isolation from the remaining code and the environment. By making those tests rely on the particular state of the web page, you lose the “unit” aspect of your tests, meaning that you'll rather have system and integration tests instead.
You're also right about the speed aspect of the tests. DOM is known for being terribly slow, so if your tests rely heavily on DOM, don't expect to run thousands of them in a second.
You're equally right that maintenance of fixtures may be a difficult task. In essence, if the HTML structure of your web application changes, you have to reflect that in possibly every fixture. If fixtures are written by hand, you'll waste a lot of time doing that. If fixtures are generated, you may end up wasting a lot of time tuning the generator itself.
The benefit of your approach becomes noticeable when the choice is between testing at least something, or not testing anything at all. If the project is under time pressure, fixtures may be a good choice to introduce your team to automated testing.
If the project is small enough, such tests may be the only thing you need: adding unit testing won't bring too much in long term and will impact the project in short term.
If the project is large but there is no time to develop a full suite of unit tests, start by system testing with fixtures. Once you have enough branch coverage, you may focus on new code, code with the least coverage and code with the most bugs to add unit tests, class by class.
An important benefit is that if your code base is not well designed for unit tests, adding them now will require refactoring, which, in turn, may generate regressions. If you already have enough system tests using fixtures, your team may be more comfortable doing refactoring when adding unit tests later, knowing that they have system tests to detect at least some regressions.
