In a clean Drupal and CiviCRM install, the CiviCRM module can be disabled without generating any errors.
Getting CiviCRM working in a local development environment that doesn't mirror the configuration of the actual site can be a pain and CiviCRM adds a lot of overhead to page loads and increases the memory required for many tasks, but the steps for resetting the paths and deleting temp files are well documented at http://wiki.civicrm.org/confluence/display/CRMDOC/Moving+an+Existing+Installation+to+a+New+Server+or+Location
CiviCRM includes handful of Drupal modules that give Drupal access to the CiviCRM data in modules like Views and Rules as well modules that do things like add or remove users from roles based on having paid their membership, but CiviCRM is much more than just those modules. CiviCRM is a large PHP project (much larger than Drupal core) that runs within Drupal, WordPress, or Joomla's menu and authentication and includes APIs and hooks that allow custom development to tap into CiviCRM at many levels with any of those CMSes.
You could probably get away with a "dummy" CiviCRM install if the site hasn't done much customization to CiviCRM or written any custom code that leverages it, but if disabling CiviCRM "throws a bunch of errors on various places" my guess is you are working with an instance of CiviCRM that has already been customized and integrated. You'd have to share the specific errors for anyone to confirm that. As soon as anyone added a custom field to one of the CiviCRM data types (profiles, contributions, events, etc), that fields could be used in a View. If a custom field is already used in a View, you have to get the client's copy of CiviCRM running or risk deleting a CiviCRM reference when updating a View.
While CiviCRM isn't Drupal, it isn't rocket science either. If you aren't sure what customizations and integration have been done, it is much safer to get CiviCRM working than trying to disable it.