Camera Angle and Position
I've put a LOT of thought into this, not only for a Pokemon game but for any top-down RPG. The approach I used was one which should take you back to high school math classes. Basically, I started with how much "weight" I wanted each face of a building to have. If you did a flat 45 degree angle, you'd see that your building's height is just as visible as its depth. I figure that a 1/2 ratio of height/depth works pretty well, at least to demonstrate what I'm doing. Remember, an orthographic camera won't scale with distance, so it would give you something which looks more like the GBA and earlier games, while Perspective will get you something resembling NDS and later.
(Ignore the fact that my camera viewport is misdrawn - I caught it and did a goofy thing where I tried to do some math which proved the camera is facing the direction the camera is facing.)
As you can see, the camera and your test building are a part of a right triangle whose sides are factors of 1, 2, and the square root of 5 respectively. The angle marked there, theta(the symbol which kinda looks like a Poke Ball, ironically enough), is the one we're trying to find.
You can use trigonometric functions to find angles given sides of a right triangle. Since we don't really care about the hypotenuse, we can just solve with Tangent. The tangent of our angle, theta, is equal to the ratio of sides we want, 1/2. Pulling out a calculator, we see that the inverse tangent of 0.5 is a little wonky, at about 26.5 degrees. You probably won't notice this rounding error unless you're working with a low resolution for your final game(which admittedly is a real possibility if you're doing a Gen 4-styled project. Use your own discretion).
The last step is the one that I neglected to show in my awful little doodle - since you're pointing your camera downwards, place your camera at (0,0,0), and then rotate it about the x-axis to 26.5 degrees.
Alternatively, you can use some scripting to define this ratio and set your camera using a facing vector which you'd normalize at runtime, but if you don't plan on adjusting your camera angles while the game is running(I can only remember Heartgold and Soulsilver doing this at the lighthouse in Olivine City), the method I outlined should suffice.
Sprite angles and positions
This really depends on how you're doing the sprites to begin with. I think Unity's 2d sprite renderer makes it so you wouldn't have to worry about this, provided you have a canvas which draws the sprites. I'd make an empty gameobject with whatever the necessary sprite components are as well as 3d physics components, then simply draw the sprites on a canvas afterward.
Player and NPC behaviors
Make them as you would for a 3d game. Just don't use a 3d object as your character's graphics, instead using whatever Unity uses for rendering sprites.
Buildings and models
Making your own?
Learn Blender. I've been working with it for the past month now, and have gotten satisfactory results. It has the benefit of being free, and it's fairly thoroughly documented. The interface is a little bizarre, but you can't argue with that price.
Want official ones?
Models Resource. They've been doing a fairly good job ripping the models from the NDS and 3DS Pokemon games, and the character meshes are weighted(though not rigged), so you can use Unity's built-in animator for it(I posted a while back a quick browser demo where I took Calem from X/Y and animated him in a box. I might still have it so I'll come back and edit this post if I find it)
Edit: I found the post in which I shared a gif of it in the early stages before I animated the arms and a link to the demo, but since removed the actual demo. Sorry about that.
