It's a 2D game made to look 3D. That's the whole point of the isometric perspective: to make it look 3D without requiring 3D hardware, 3D development, and 3D art and models. There are only bitmaps that are drawn with a 3D look.

how do you do that shadows?

Not sure how BG did it, but you could also blend your shadows/occluded sprites.

Possbily in layman's terms? ;)

Well here is one approach. Start with a prerendered 3d scene or a hand drawn image for a map. The entire map is one single large image, unlike tile based maps which are composed of small sprites and tiles.

This map has several layers, each one an image. The first layer is the artwork of the map which the players see. Then you have a set of greyscale layers which encode information about the map layout. One layer would hold the walk information, anywhere the player can't go is marked on the image and if they move the mouse over that spot the cursor changes to indicate they can't walk there, movement into those regions is blocked.

Another layer holds occlusion information. Any region of the map where the player would be behind the geometry in the map is marked in a color. You take the player's position and look up the value in the map there, if it is marked as occluded then you blend the player sprite with the map image instead of drawing the player sprite over the map image.

Now there is a subtle issue here in that you could have a thin wall that the player could either stand in front of or behind. If you compare every pixel of the player sprite against the occlusion map then the player will be blended in both cases. One solution to this is to realize that in general in isometric perspective, "above" implies "behind", so you could use a point at the player sprite's feet to do the lookups.

Shadows would be harder but the general approach would be the same. You would have a brightness map that encodes the shadow values for each pixel, and use that brightness to modulate your sprites as they move through the map. This could be used for both shadow and light.

I see two issues here however. The first is that you can no longer just lookup the pixel at the player's feet. You will need to sample every pixel the sprite covers. This brings back the problem where a single pixel in the map represents multiple voxels in 3d space. The second issue is that since a sprite has no 3d information, a shadow falling accross it will not be correct. This is going to be most noticable on large, non convex sprites and with sharp shadows.

I think you can probably fudge this enough to get a good looking effect if you are careful with you art. Don't have sharp shadows and high contrast light changes. Since your sprites won't be casting shadows, or at best casting blob shadows, you want to go with subtle lighting anyway. Also try to avoid situations where a small number of pixels divides two different scene volumes with different lighting properties. (Don't have situations where a wall that a player can stand in front of or behind casts a strong shadow).

If you are using rendered 3d scenes for your maps you may be able to auto-generate the lighting and occlusion maps, otherwise you'll have to draw them by hand.

It's been a while since I did anything with the infinity engine so this probably isn't exactly the approach they used. However if you take a look through their data files you can see the maps they used and get some good ideas. I'd recomend takeing apart bg2 anyway to anyone who is interested in making 2d rpgs, you can learn a lot by looking at how they did stuff.