On the one side, it isn't different. On the other, it is.
Models typically use bounding volumes (e.g. boxes) for collision detection, and only the really important stuff gets mesh-accurate collision detection.
Models are typically loaded into memory fully. You either need them or don't.
Terrain on the other hand isn't needed completely. You only need parts of it, commonly refered to as chunks. Those chunks could be individual models, but more often then not they aren't.
Terrain needs LOD, and with LOD comes stitching problems. So chunks need to be aware of their LOD state and the LOD state of the neighbouring chunks - a common solution is using quad trees for terrain.
Moreover, collision detection against terrain can often be simplified. If your terrain does not have holes but is derived from a height map, you can greatly simply collision detection by only checking the height of the bottom vertices of your chracaters bounding volume against the hight of the terrain at that point.
You will want to have your terrain in a data structure that supports frustum culling and potentially caching / paging (if a player goes back and forth a lot).
All in all, terrain is vastly different from normal models due to its sheer size. But at the end of the day, your piece of terrain is just a mesh with a shader and a few textures, just like any other model, too. So not so different after all.
You need to ask yourself what your terrain - for your game - has to be able to do. And then support that.