To large extent this may have been resolved by prior replies to the list, but I figure I may as well clarify for your sake if no one else's!
Suppose I have a model of one chain of a complex and an .mtz describing the entire complex.
 I'm struggling making sense of this statement.. MTZ file is just a file format to records some data with labels associated with it in a binary form to make it easier for machines to handle it. So what precisely you mean by ".mtz describing the entire complex"?

Precisely, I mean an .mtz that contains experimental structure factors. (The use of "describing the entire complex" may be redundant, and my use of that phrase may rest on a misunderstanding that I'll be able to refer to later.)

For obvious reasons,

phenix.model_vs_data chain_A.pdb whole_complex.mtz
phenix.model_vs_data chain_A_refined.pdb whole_complex.mtz

are undesirable: they evaluate the model of a single chain against the whole complex's data, and there's obviously a lot of unsatisfied electron density. So, while this command works, it reports an unrepresentative fit.

Could you please define "unrepresentative fit" in this context?

Well, suppose that the structure factors in whole_complex.mtz reflect a tetramer. I would imagine that part of the reason that the resulting Rwork and Rfree are poor is because the model contains only one chain; with all four chains, the fit would be considerably better.
(In theory, one solution to my problem would be to re-combine each chain's refined version, then run model_vs_data on the recombined, refined complex. I'm interested nonetheless in how it would work on the chains separately.
 I guess Fobs would not like this as they include contributions from all atoms, as far as I remember from the theory.

Yeah, I think that was the key conceptual issue I was having. Rationally, I had no idea how there could possibly be a subset of Fobs that could be associated with a subset of the atoms. But phenix.maps, being handed a PDB and a MTZ file of structure factors, hands you--in addition to a .ccp4 map--the rather generically named map_coeffs MTZ file. Looking more into the documentation for maps.params, it's probably just separate data:

> mFo-DFc and anomalous difference maps will be output in MTZ format

So it's possible that this entire line of not-quite-logically-consistent questioning arose from an incorrect assumption about the meaning of the output map_coeffs MTZ.
Now, during the refinement procedure, we of course generate .ccp4 density maps for the individual chain models:

phenix.maps chain_A.pdb whole_complex.mtz
 Well, this is what it seems *you* do as part of *your* protocol, but this is *not* what typical work-flow includes as phenix.refine always reports maps upon completion of refinement; so running phenix.maps seems to be an unnecessary step in this scenario.

Well, I intentionally didn't mention a particular refinement protocol: I'm not using phenix.refine, but--in what I'm testing at the moment--an external real-space refinement that uses the .ccp4 map to provide restraints.
...
 Hm.. I afraid I'm lost now: model vs data tool is not supposed to accept inputs other than original data, Iobs or Fobs, and model files.

Right: this was due to the aforementioned conceptual error re: what the "map_coeffs" output really represented.