Legal discussion
To ISM or not to ISM, that is the question
So, in Europe, 433 MHz is an ISM band – you could even operate a device there if you weren't a licensed Ham! That also includes the fact that if you choose to go for unlicensed operation rather than amateur licensed operation, the no-encryption rule, and the callsign rule (both of which frankly don't make overly much sense in this day and age, in my humble opinion) don't apply to your use case. Now, in the US, it's not an ISM band, but if I read your question correctly, it wouldn't hurt you if you had to switch to the 900 MHz ISM band. (whether you do that or not doesn't really matter for the technical discussion below)
ISM band situation
Now, that's about how much legal advice about the situation in the USA I can give; I'm not a lawyer, and a European on top of that. Generally, even ISM-band devices must adhere to regulations. It really depends on the legislation, but for example, in Europe, there's what we call "Short Range Devices", and the rules these must fulfill are rather lax – depending on the band, low duty cycle, low transmit power and negligible out-of-band emissions ensured by "appropriate" engineering. Nothing about spending a few grand on lab testing and certification as necessary for other operational classes.
Technical discussion
Tickling you with a bit of background
Now, your weather station needs pretty much next to no data rate at all – you can happily spread out energy as much in time and/or frequency as you want to, given you then "collect" it at the receiver again. That's what for example GPS does – the satellites' signals at the receiver are usually all below thermal noise floor, but due to integrating over enough time, your GPS still works reliably.
We typically call these technologies spread spectrum. There's quite a few different implementations. For example, if you want to work with readily engineered long-range modules that you can just wire up to a microcontroller and easily talk to, LoRa is a manufacturer-proprietary technology for machine-to-machine communication (M2M, exactly what you're doing!) in ISM bands. It should work reliably over the comparatively short distance you're trying to cover, even if it uses higher frequencies. It uses what they call Chirp Spread-Spectrum, which is an interesting thing to do, though not inherently extremely intuitive from a theoretical point of view.
If you instead want to build this yourself, you could very easily build your own spread-spectrum transmitter. It's not hard at all – in fact, if you have a transmitter that uses a linear modulation, and can feed it with any data stream you want, it's pretty easy. Think about Direct-Sequence Spread Spectrum, DSSS: Typically, you just go and multiply a symbol by a symbol sequence and transmit that. Imagine, you want to transmit the bits 110011. Now, you say that a 0-bit is -1, and 1-bit is +1. Instead of just transmitting +1 +1 -1 -1 +1 +1, you pick a sequence, let's say +1 +1 -1 -1 as spreading code.
Then, you take each of your transmit symbols, and multiply it by the sequence (so you replace +1 by +1 +1 -1 -1 and -1 by -1 -1 +1 +1), and just transmit the result (after concatenating what you've got):
+1 +1 -1 -1 +1 +1 -1 -1 -1 -1 +1 +1 -1 -1 +1 +1 +1 +1 -1 -1 +1 +1 -1 -1
At the receiver, you just correlate with the same spreading sequence. That basically means you're taking the received signal, four values of that, and multiply it point-by-point with +1 +1 -1 -1, then sum up the four values you've gotten, and get an amplitude. Then, you shift your input signal by one, and do the same. Whenever you get nice and high values, you've "hit" a transmit signal (instead of just noise).
There's a bit of a trick to picking these spreading sequences. You want them to have a well-shaped autocorrelation function, meaning that when you multiply them with themselves, shifted by any amount of time but 0, they will have low values, but high values when multiplied-summed without any time offset. That way, you can actually successfully synchronize your receiver to your transmitter and eliminate as much of the channel influence as possible.
From this requirement comes that you get better performance for longer sequences (that's kinda logical – the more values you add up, the higher your value gets if you're actually multiplying with the right sequence instead of noise), and that you'll pick sequences that aren't periodical in themselves – because if they were, they'd be similar to a shifted version of themselves, and thus would not fulfill the autocorrelation criteria. If in doubt, Gold codes are a good source of such sequences, and don't be shy about length – modern wide area network standards allow for sequences up in the dozens of thousands of symbols in length¹.
Thus, if you have a transmitter that can either send +1 or -1 (or QPSK, or anything that is a linear modulation, which pretty much is everything but plain FSK, really), then you can also make it send +sequence and -sequence just by replacing the raw data with the coded data. To let your receiver know that you're about to start sending data, you could also prepend your callsign to the weather station data, and encode that along with it. That would a) give you a preamble and b) fulfill the ham callsign requirement.
Implementation approaches
Buying dedicated RF transceiver chips / boards
You could implement that transmitter with a cheap microcontroler that integrates a radio frontend; for example, TI sells the CC1310, and an eval kit board costs 30$ (also comes in a 433 MHz version. Haven't worked with that, but the chip does come with built-in support for spreading sequences, so that sounds nice for your application, and you could have one on both ends of your link, and probably TI will give you some example code to make them talk to each other.
A quick word about why these devices exist
Notice: exactly what you're building is something that is of large commercial interest, so it's no big surprise TI and other companies try to make it easy to use their products to implement what you want! Integrating that with a microcontroller makes a lot of sense – people that build devices like weather stations don't want to have yet another chip on their board that only does the RF, and then a microcontroller to control that RF chip, and then hope that they can avoid having yet another microcontroller just to control the weather sensing devices, they want one controller to at least do the job of the RF interface reliably, and they want someone who had the time to test all this to have implemented the radio control layer. Makes much more sense that way.
A self-built receiver
If you want to implement the receiver yourself, you'll need the correlator, and something to sync. You said you had an SDR – I simply postulate that as you're building something cool, another 10$ RTL dongle won't hurt you much, so you can just receive that signal, and do the above correlation (which, really, is just a FIR filter with the reversed sequence as taps) in software – for example, on a cheap small computer like the raspberry pi.
I'd go into detail here – but "how do I build a DSSS receiver with a Raspberry Pi, an RTL dongle and minimal effort, matching my transmitter" would be worth opening a new question, if this is the way to you choose to go, and I don't want to overburden you with details at this point. But really, other people have built SDR receivers (and transmitters) for such systems. For example, see this gr-lpwan presentation that, with less than 5 mW transmit power worked on 2.4 GHz (which has more than 10dB more path loss for the same distance than 433 MHz, if I'm not mistaken!), worked over a couple of kilometers, even in the shadow of large buildings; don't let yourself be scared by the math and complexity. This is a full implementation of a complex standard, not a "works for my weather station (and that's enough for now)" approach.
¹ Talking about IEEE802.15.4-LECIM in case anyone wonders.
