So does single-assertion testing violate DRY?
No, but it promotes violation.
That said, good object oriented design tends to go out the window for unit tests - mostly for good reason. It's more important that unit tests be isolated from one another so that the test can be interrogated in isolation and if need be, fixed with confidence that you don't break other tests. Basically that test correctness and readability is more important than its size or maintainability.
Frankly, I've never been a fan of the one assert per test rule for the reasons you describe: it leads to a lot of boilerplate code that is hard to read, easy to mis-boilterplate, and hard to fix well if you refactor (which drives you to refactor less).
If a function is supposed to return a list of "foo" and "bar" for a given input, but in any order it is perfectly fine to use two asserts to check that both of them are in the result set. Where you get into trouble is when a single test is checking two inputs or two side effects and you don't know which of the two caused the failure.
I view it as a variation on the Single Responsibility Principle: there should be only one thing can cause a test to fail, and in an ideal world that change should only break one test.
But in the end it's a trade off. Are you more likely to spend more time maintaining all the copy pastey code, or will you spend more time hunting down root causes when tests could be broken by multiple sources. As long as you write -some- tests, it probably doesn't matter too much. Despite my disdain for single-assert tests, I tend to err on the side of more tests. Your mileage may vary.