No not automatically. As Daniel states above, the latest Starling will support a 'scale' property on textures as well as scaled rendered text based on a computed Starling.contentScaleFactor. It is up to your code though to use non 1.0 scale values.
Starling.contentScaleFactor is not something you set directly but is a computed ratio of your current Starling stage's viewport size compared to the stage's stageWidth/stageHeight
You would need to check the Starling sample code for an example of how to take advantage of this feature. The sample uses an Assets class to choose to load different assets from alternate 1x, 2x classes and also creating textures with a scale parameter overriding the default '1'.
Typically when your app isn't worrying about different resolutions you are either manually or having Starling automatically set its
stage's stageWidth and stageHeight equal to it's viewport rect's width and height respectively.
This means your stage's coordinate system is mapped 1-to-1, pixel-to-points when they are set to the same width and height values.
In the case of the Starling sample iOS demo code it uses explicit iPhone sizes.
It *always* sets stageWidth = 320, stageHeight = 480. On a non-retina iPhone
the viewport width will be set to 320 and viewport height will be set to 480, and the Starling.contentScaleFactor will be 1. But on an iPhone retina device the viewport width will be set to 640 and the viewport height to 960 and now Starling.contentScaleFactor will report '2'. The Assets class in the demo app uses Starling.contentScaleFactor to help it figure out which of the 1x or 2x asset classes and texture scale values to use.
As another more generic example that isn't iOS specific:
Lets say that you add a resize listener in your startup class on the flash stage:
// this is the flash stage
stage.addEventListener(flash.events.Event.RESIZE, onResize, false, 0, true);
then, where you might normally update the Starling stageWidth and stageHeight *and* the viewport rect width and height to the same new values, you instead inject some conditional logic to decide whether this device should instead use 2x (or even 3x) scaled coordinate system:
private function onResize(e:flash.events.Event):void
{
// note this is the flash stage.stageWidth/Height in a startup class, not root class
var newViewportWidth:Number = stage.stageWidth;
var newViewportHeight:Number = stage.stageHeight;
var desiredScaleFactor:Number = 1;
// you want to check if on iPhone or iPad retina...
if (iOSRetinaDeviceTest) desiredScaleFactor = 2;
// maybe for Android you use 2x assets with high screenDPI
if (Capabilities.screenDPI >= 220) desiredScaleFactor = 2;
// maybe you have some super-rocked out device needing 3x assets
if (amazingSuperHDTest) desiredScaleFactor = 3;
// note you might need to check if Starling stage is up yet...
Starling.current.stage.stageWidth = newViewportWidth/desiredScaleFactor;
Starling.current.stage.stageHeight = newViewportHeight/desiredScaleFactor;
Starling.current.viewPort = new Rectangle(0,0, newViewportWidth, newViewportHeight);
}
Now Starling's stage stageWidth/stageHeight might not match the viewport dimensions so the pixel-to-points ratio will change and Starling.contentScaleFactor will reflect the proper scale factor.
It is still up to you if you implement something like the Starling demo's Assets class to check and use the current Starling.contentScaleFactor to pick the right 1x,1.5x.2x,3x.. asset class (and actually implement that new scale class) and also when it calls for loading textures to ensure the scale parameter reflects the current Starling.contentScaleFactor.
Hope some of that helps a bit...