Well, after more investigation it seems likely after all that the session doesn't use an allocator itself but relies on the individual components being D3D aware. The same thing seems to happen with the source reader.
Although it reports MF_SA_D3D11_AWARE (and MF_SA_D3D_AWARE on Win7 only), the video processor *is* D3D aware, and I intend to implement it. I also suspect that it is somehow involved in the D3D9 case even though it doesn't have the MF_SA_D3D_AWARE attribute on more recent Windows. Maybe MF_SA_D3D11_AWARE implies MF_SA_D3D_AWARE.
As long as either a decoder or a video processor is present in the pipeline, there is no need for an external allocator or sample copier.
Still, I'm not completely sure how video sample notifications are supposed to be used, or if they even are. It looks to me that if we can starve the allocator somehow, and without notifications, it could stall the pipeline.