I don't think testing test cases themselves, beyond running them and getting a code review, makes sense. However, testing reusable test code makes some sense; the question is whether it makes enough sense to justify the time that would be invested. I think that question needs to be answered component by component.
I don't generally do testing of test code beyond running test cases as I create them to ensure they behave as expected. I've come to realize that the test cases I run are implicitly testing my test harness / fixtures every time those test cases are run. I do execute a test run after making significant changes to test code on a previously tested project, to ensure that I am not getting different test results on the same piece of code. Getting different results would suggest a test code bug, so regression tests for other features end up also being regression tests for my test code. In general, I find tests and test code tend to "test themselves", since most test bugs cause the test checks to fail. The biggest exception is the test harness, which exists before any tests do, and gets some basic tests to ensure that passes and fails are recorded correctly, data is properly loaded from the DB, etc.
I have occasionally found test bugs where the test case wasn't testing what I thought it was. However, these are rarely caused by testing code bugs IME (after the first successful run) and are usually caused by either a bad specification or bad test data (e.g., running the wrong file through the test). These kinds of bugs are difficult to test for; bad specs are best found through intense curiosity, and bad test data is usually only found when a bug doesn't make a test fail but should have, and is detected through some other means (often another test case that implicitly tested that behavior).
IME, all testing needs to get on the backlog in one form or another, but specifics don't matter as much. We currently make test harness changes their own user stories, but fixtures and test cases are tasks on the relevant user story being tested. I've done it the other way, with all testing tracked as its own project, but that tends to hide testing a bit more. I think the main thing is that testing gets written down somewhere where it will be taken seriously and get attention when people are making their scheduling decisions.
I know my tests are good quality when I see my tests finding lots of bugs and very few bugs getting through. I can guess my tests are good quality when I see a strong correlation between how many bugs I find and what the quality of the product seems to be. There have also been occasions where I have "parallel tested" software, myself automating and a black-box tester using exploratory techniques. I've found that we find the same number of bugs, with 80% being the same issues and about 20% each being different, but of similar severity and priority, in the same time frame. This has given me a great deal more confidence in my test automation skills.
Some testers do more than this, however, using techniques like mutation testing. Mutation testing is when a set of artificial (perhaps random) small changes are made to the system under test. The question then becomes, does your test catch those changes? If the production code is well-designed without dead code, you should be picking up those regressions. "Beautiful Testing" has a chapter on mutation testing in part III of the book (chapter 18).