The func_occluder hides entities from you, simple as that. It can be turned on and off by triggering it to do so.

You make one by making a brush with the NODRAW-texture, and giving the occluding sides the "tools/toolsoccluder"-texture. ONLY THE OCCLUDING SIDES SHOULD GET THIS TEXTURE.

The occluding side is marked RED. All other sides of this func_occluder should be NODRAW. In the picture, purple entities are hidden, blue ones are still drawn. The occluding side is the brush-side which the player has to look through in order to occlude the entities behind that face. So if the player was south of this occluder and you wanted to occlude some entities north of this occluder, the south brush-side of this func_occluder becomes the occluding side. Confusing? Nah. Experiment with the example map and you will know what I mean.

Awesome? Not really. Some bad point:

• Func_occluders work real-time. That is, while playing your game, the engine has to decide which entities are, or aren't blocked by any func_occluder. This requires some calculating power, therefore you have to make them worthwhile: a func_occluder has to hide at least a few (more or less) complicated models to be effective. Failing to do so will lower FPS, because the cost of the func_occluder becomes higher than its profit. To check, run your level and use "r_occlusion 1" and "r_occlusion 0" in the console to see where you get the best performance. If "r_occlusion 0" gives you higher FPS, ditch your occluder, otherwise keep it. Simple as that.
• The occlusion for entities is calculated per side. The engine has to decide for each brush-side with the OCCLUDER-texture if it does or doesn't occlude a certain entity. That is why you should only give the occluding sides the 'tools/toolsoccluder' texture and the rest the nodraw-texture. That is, only the front of the occluder should get the occluder texture. Even the small sides of the brush could bring down the FPS dramatically, even though they aren't needed in the occluding process. 
• Func_occluders only block entities, not brushes. If you want to block brushes as wel, use an areaportal instead. Also, shadows (even of blocked models) are still drawn.

Using r_visocclusion (again 1 is on, 0 is off ) you can see your occluders in action:

red means entity is drawn
green means entity is blocked (not drawn)
white lines denote active func_occluders
entities that aren't affected by occluders have no border

func_occluders don't need vis or rad to be run, and work on maps with leaks too ( though not really usefull, it does imply you can test them while having leaks ). They can cause errors when touching a func_areaportal or when being in a brush that touches more than one area ( "Warning: func_occluder straddles multiple area's" ). An area is defined as a part of your map sealed of by areaportals and world brushes.

An example of usage is ( like in my example map ) a func_breakable, which blocks vision of models, but once its broken it deactivates the occluder so the player can see all the models like he should:

Sometimes it's better to use an areaportal for things like this, but they are not always possible. Occluders can easily be used inside entities which cover up a lot more entities. Or inside hills, where they could cover up entities on the other side of the hill like in the areaportal example.

My recommendation is to use this entity as a last resort, you can hardly use it to such an extend they are worthwhile. Unless you have a space with a lot of entities. Always try hints and areaportals first. And if you can't get enough effect of them, try again. And again. And again. Only after you've tried for more than two months should you start considering occluders.

The example map by Valve about occluders can be found here: "sourcesdk_content\hl2\mapsrc\sdk_occluders.vmf"