If anyone is reading this, there is a way to control pixel position in the vertex shader, ofcourse :). But you need to remember two things:
1) if all vertices end up in the same position - no pixels will be drawn, so you must specify a region between at least 3 dots;
2) the GPU will interpolate the region you entered across your rendertarget, minding the latter's size, so in the end for every triangle you draw, only one pixel will get drawn for pixel slot in the rendertarget. So two pixels will end up in the same spot fighting for it ONLY IF they belong to two different triangles.
One more thing I wanted to add. I was asking this question as I had an idea about a pixel-perfect collision detection system in 2d world FOR A NON-PIERCING BULLET (the piercing one can be easily implemented with occlusion query and stencil buffer). I dropped the idea as it's solution was infeasible and inefficient. However, there is one approach one could theoretically employ. You don't even need DX10/11 for this. The thing is, if you have your scene with monsters drawn into it using their numbers and not colors, and it you then use this scene as a texture in a shader, you can paint a bullet over it and compute where it hits the monsters. Each pixel will even know WHICH monster it hit, and you can even compute the difference from the end of the barrel to the pixel. However, you will end up with a tone of pixels and won't be able to tell which one is the first one in the bullet's way. To solve that, you can take call tex2D() in each pixel's shader multiple time IF you can compute the UV offsets for EVERY pixel of the bullet's trajectory. Then each pixel will know it's hit data, and the data for neighboring pixels and output only the data for the nearest hit. Thus you will end up with a line that consists of several blocks of pixels. In that case you will need to run the shader one more time to refine it to a line consisting of pixels each of which has the same data - which monster is the first one to hit. Then you simply call Texture.GetData for a single pixel region and end up with a monster number. If you will make a call in a different thread - you can read data later without program stalls.