Argh! I had a whole bunch of explanatory text following the code, but it looks like the editor ate it. Sorry about that.
The typeless format is definitely the trickiest part of this. Basically D3D will make the distinction between depth and color formats, so if you want to alias a texture using both types then you need to use a TYPELESS format when creating the underlying texture resource. Then you use the "D" format when creating the depth stencil view, and the "R" format when creating the shader resource view. This way the depth stencil view interprets the data as a depth buffer, and the shader resource view interprets it as a color texture.
The code I posted doesn't actually handle cubemaps, it just handles texture arrays. However cubemaps are really just a special case of texture arrays with an array size of 6. You'll definitely want to continue using D3D11_RESOURCE_MISC_TEXTURECUBE flag if you're creating a cubemap. To render to each face individually, you'll want to do something similar to what I'm doing in the code I pasted where you create 6 separate depth stencil views. When you create the DSV, you can essentially bind it to a single slice of a texture array. So you can use that to effectively target a single face. Then just bind the appropriate DSV to your context when rendering. Also note that if you're using a cubemap, you'll want to use D3D11_SRV_DIMENSION_TEXTURECUBE (along with the corresponding TextureCube member of the SRV desc structure) instead of Texture2D or Texture2DArray.
The read-only DSV is just something I've used in a few special cases, you probably won't need it. Normally D3D doesn't let you bind a depth buffer to the context if you also have it simultaneously bound as a shader resource view. This is to prevent read-write ordering conflicts. However if you create a read-only DSV, then you can have it bound as both a depth buffer and an SRV simultaneously since it's read-only in both cases. However you of course can only do depth testing like this, and can't enable depth writes.