Creating a stand alone for this feature issue per the services module maintainers request.
For the root of the issue see: #2400075: List and Entity Reference Field Issues

Here's the parts affecting entity_reference:

Because services uses drupal_form_submit to save entities it creates a problematic api. I would expect that a user object pulled from the api could be put right back in the same format. But, drupal_form_submit has an issue when it comes to certain types of fields. Entity reference (select for certain, other widgets perhaps), seem to be affected. When posting data in the format found on finished nodes (field[lang][0][value]), the form api triggers the following message for each field of that type:

Illegal choice in {field name} element.

Warning: Illegal offset type in isset or empty in _form_validate() (line 1368 of includes/form.inc).

The data coming into the services processor can be affected through hook_services_request_preprocess_alter in order to manipulate the standard field based structure into the required form api structure. An example code snippet looks like this:

/**
 * Allow to alter arguments before they are passed to service callback.
 *
 * @param $controller
 *   Controller definition
 * @param $args
 *   Array of arguments
 * @param $options
 *
 * @see services_controller_execute()
 * @see services.runtime.inc
 */
function hook_services_request_preprocess_alter($controller, &$args, $options) {
  // Look for node and user callbacks to correct the argument format automatically
  // @see http://drupal.stackexchange.com/questions/61124/drupal-7-services-3-inse...
  // @see https://www.drupal.org/node/1195306
 
  // No callback? No work
  if( empty($controller['callback']) ){
    return;
  }
 
  // Not one of ours? Skip it
  if( !in_array($controller['callback'], array(
    '_user_resource_create',
    '_user_resource_update',
    '_node_resource_create',
    '_node_resource_update',
  ))){
    return;
  }
 
  // Determine the entity type
  if( $controller['callback'] == '_user_resource_update' || $controller['callback'] == '_node_resource_update' ){
    $entity =& $args[1];
  } else {
    $entity =& $args[0];
  }
  $language = !empty($entity['language'])? $entity['language'] : LANGUAGE_NONE;
 
  // Get a field dump of properties associated with this entity type
  $fields = field_info_fields();
 
  // Modify the input of all incoming data for fields of type entity_reference
  // or using the select widget
  foreach( $fields as $field_name => $field_settings ){
    // Skip non-problematic fields
    if( !in_array($field_settings['module'], array('entityreference')) ){
      continue;
    }
 
    // Skip fields that are not present in the posted data
    if( !array_key_exists($field_name, $entity) ){
      continue;
    }
 
    switch($field_settings['module']){
        case 'entityreference':
          if( empty($entity[$field_name][$language][0]['target_id']) ){
          continue;
        }
        $values = array();
        foreach( $entity[$field_name][$language] as $field_item ){
          $values[] = $field_item['target_id'];
        }
        $entity[$field_name][$language] = $values;
 
        watchdog(
          'services'
          ,t('Entity %field_name argument rewritten by custom programming. <pre>!data</pre>')
          ,array(
                '%field_name' => $field_name,
                '!data' => print_r($entity[$field_name], TRUE),
          )
          ,WATCHDOG_INFO
        );
        break;
    }
  }
 
}

I've tested the above code as a solution for a site I'm currently building. But, it does not take into account the breaking change this would implement on code already in production for issues like #1440986: JSON query. Additional handling will be required to avoid disrupting their solutions.