Si la funcion __delay_ms() tiene un limite de :
must be a constant and less than approximately 179,200 for PIC18 devices and approximately 50,659,000 for other devices.
esas cantidades de ciclos xD, imagino que el ultimo valor debe ser para micros de 16 y 32 bits.
Es correcto el funcionamiento en la simulacion de Proteus, como dije o no se si me exprese mal, los que usan el XTAL_FREQ son las funciones __delay_ms() y __delay_us() , en estas usan el valor dado del cristal para calcular la cantidad de ciclos y asi usar las funciones esas de esperar 10k de ciclos o 1k o ciclos. Si vas a usar estas funciones entonces ahi SI va a cambiar la frencuencia. Ciclos = Tiempo * XTAL_FREQ / 4
Ahora si vas a esperar 200 * 10k de ciclos va a depender unicamente de la frecuencia de operacion del micro ( 48Mhz ) y no del valor de XTAL_FREQ por que no se usa para calcular nada ( antes calculabas los ciclos con eso, ahora se los estas dando vos mismo a los ciclos, no es necesario calcularlos).
Es por eso que no varia en tu simulacion el delay variando el XTAL_FREQ, si quisieras verlo variar por modificar esta variable entonces usa las funciones que nombre.
Cabe destacar que XTAL_FREQ no es una condicion o exigencia hacia el microcontrolador es un valor definido como cualquier otra que puedo crear usando la directiva #define
#define PI 3.1416
Reemplazando el compilador cualquier PI por 3.1416
El delay maximo que podes lograr con __delay_ms a 48Mhz es de 14.9mS ( 179200 ciclos), asi que podrias hacer uno de 10ms y que entre 100 veces. Asi da 1 segundo. Y podes probar cambiando el valor de XTAL_FREQ, poniendolo en 24Mhz deberia cambiar cada 0.5s. Y si se te ocurre cambiar la frec de simulacion a 24Mhz entonces vas a tener un cambio cada 2seg. Esto es solo a modo de prueba.
Proteus por mas que le pongas un cristal va a hacer caso a la frecuencia puesta en la configuracion del micro. Creo que lo unico que simula es el WDT, no se si otra cosa mas de los FUSES.