I must admit, normal maps never seemed like the kind of thing that a person could draw and remain sane... Bump/Height maps, certainly -- pretty straightforward. But a normal map, with the surface normal's unit vector's x,y,z encoded in r,g,b?
(Technically, I believe you're encoding the "relative" surface normal, or the delta of the desired surface normal from the underlying 3D model's surface normal. Which makes sense and is what you'd expect, I just wanted to be clear that it's more dx,dy,dz rather than any kind of global x,y,z coords. And, I suppose, it should be du,dv,d?, since you only know texture coords, not model coords.)
(Then you get the extra weirdness of needing to keep it a _unit_ vector. While you're getting your tilt angles right, make sure the length is 1.0, or the lighting calculations will do weird things. Oddly enough, there must be some reason to want to allow "weird things", because if you were only going to allow unit vectors, you would only need to specify du,dv at each pixel, and d? could be calculated as "whatever makes the vector have length 1.0". That could be done by the hardware, though the resulting calculation involves some square roots, which are expensive at the pixel level, so maybe they just said "sort it out yourself offline and just tell us sane numbers")
Every one I've ever seen gives me a mild headache. Straightforward enough if you're starting with a high detail 3D model and baking those fine details down into a normal map to apply to a low-poly game model. Computers have no problem with it. And I could see doing a brick texture, I guess. Left edges of bricks would have low red intensity, right edges would have high red intensity, top edges would have low green intensity, bottom would have high green intensity. But for anything organic, or even just rounded? Brain hurts.
Now, I could definitely see how to have a program go from a bump/heightmap to making a normal map, but if that's all you're doing, why supply normal maps? Why not just supply the bump/heightmap? And then I realized that it's probably for the same reason as providing the third d? component -- it saves the pixel shader from having to calculate the local surface normal and just give it to it directly.
Which is a very long-winded way of saying that I'm impressed by anybody who is making normal maps by hand... And that I appreciate your devotion. If a bump->normal program would be useful, I'd be happy to contribute such a thing.
(I'm also aware that I haven't kept up with tools, and haven't played with Unity yet, so I apologize if this entire post is ridiculous and/or misguided...)