The advantage is it protects your DTO against future "enhancements" ?
Let me say, first of all, that coverage for coverage's sake is bad. Writing a unit test for your class's constructor, just to make sure that NCover or dotCover sees that the runner went through the constructor code, is worse than useless. If the test makes no assertions, then your build-bot's coverage metrics give a false sense of security. If it does make assertions, then the test will have to change if the assertions ever do, even if no other line of code will care.
Therefore, the answer to your title question is predicated on another question: Do the tests make assertions that other elements of your codebase, or your end users, will care about?
The question isn't about how basic the system under test is; a test that
Add(1,2) == 3 can be useful, if that's what the code needs to do and you need to ensure it always does this. It's also useful if you're TDDing (which IMO you should be), because when you make this assertion, the code that will make it true doesn't exist yet. In TDD, no matter how simple an action may be, as long as you need a line of "end-developer code" (not built into the language or a third-party library) to perform an action, you need an assertion that proves you wrote that line of code correctly.