What you are trying to do, if I am understanding you correctly, is effectively a form of policy routing with some NAT involved. It sounds like you are just looking to create an alias for some host outside a particular routed subnet which is on that subnet.
You can create DNAT rules without corresponding SNAT (or masquerading). The reason this isn't done is merely that most NAT is designed to hack around a connectivity issue whereby the addresses on the "inside" of the NAT wouldn't otherwise be routeable from the "outside". If in fact the host 192.168.1.1 has a route back into 192.168.2.0/24 or whatever it is, you can indeed just set up a DNAT rule if I recall:
iptables -t nat -A PREROUTING -s 192.168.2.0/24 -d 192.168.2.1 -j DNAT --to 192.168.1.1
Now, stop for a moment and don't do that just yet.
That works when 192.168.2.1 is a destination address (and creates an odd quirk whereby the address replying to traffic is different from the original destination). I don't think that's what you want to do, from your description, though I'm honestly not sure. Doing DNAT won't help at all if the 192.168.2.1 host is supposed to act as a router and not as a destination. If it's supposed to act as a router, NAT (or PAT) won't help at all.
It sounds like you have VPN traffic coming in which ends up bridged onto this subnet 192.168.2.0/24 if I am reading you correctly and filling in the blanks as they are, and it needs to get out to the wide world or some subset of it via this gateway 192.168.1.1. In that case, the thing to do is to simply assign 192.168.2.1/24 (which I suppose you have set as the default gateway on the VPN clients) to your router, make sure forwarding is enabled, and you're good to go - the VPN clients don't ever need to worry about the next hop being 192.168.1.1 just like their original default non-VPN gateway (home gateway?); they are completely unaware of it as the packet transits. ISPs use this kind of scheme with RFC1918 addresses all the time to avoid wasting accidentally-scarce routable addresses; it is not a requirement that all the routers along the path have unique addresses at all (though when they do have, it makes troubleshooting a lot easier). The trick here is that the endpoints of a TCP connection don't need to know anything but the IP address of the next hop.
If you're already doing this and you're having trouble, check the return path. Chances are your gateway at 192.168.1.1 isn't doing NAT for those addresses when sending their traffic outside your NAT (which it will see as 192.168.2.0/24 still), is firewalling them, or doesn't have an appropriate route back to 192.168.2.0/24.
If I've misunderstood your intention on both counts, there is a third thing that might help you. The one and only way you can specify a gateway in iptables is with the TEE target, which clones the packet and routes the clone unchanged to some arbitrary host. You'd need to deal with the not-cloned packet somehow, though. That target can be added in the mangle PREROUTING chain:
iptables -t mangle -A PREROUTING -s 192.168.2.0/24 -j TEE --gateway 192.168.1.1
That is a weird thing to do; this is designed for logging traffic, not routing it. You could dispose of the original packet at some later stage of iptables I suppose, though this is just a mess and I really don't recommend it.
As a random point, you can add additional IP addresses to interfaces using the
ip addr add command. Don't use net-tools (ifconfig); it is ancient and missing many features and will only give you headaches in the long run.