Well, after the re-install it looks a little more confusing to me than before.
First of all, you could make a Web search or ask in the SuSe section if anyone ever has installed that modem with Suse.
If you do an "lsusb" or an "/sbin/lsusb" you should see some output like this:
Bus 003 Device 001: ID 0000:0000
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 004: ID 050d:258a Belkin Components
Bus 001 Device 001: ID 0000:0000
where instead of the cable from Belkin should pop up your modem.
The first 4 hexadecimal number in front of the colon (here 050d) is the vendor ID, the second 4 digit hexadecimal number (here 258a) is the product ID. With those numbers you make a Web search to get mostly technical hits that might deal more with technical questions.
Also it specifies exactly the same hardware that maybe is sold under different brand names.
Having done this and hopefully having not got many hits with people saying it's unfeasible, let's try again things from bottom up.
First, I don't understand why the drivers shouldn't be installed.
On the "dmesg" output who is talking? Presumably a driver named "slusb".
Check with "lsmod" or "/sbin/lsmod" all the drivers that are loaded. If there are many check the existence of slusb with "lmsod | grep slusb".
I presume there is a binary "slusb.ko" of a driver loaded (in the lsmod output it's without ".ko" at the end) that names itself "ST7554 USB Modem". If the driver usbcore loads a driver it prints out simply a string that the author of the driver specified, in this case "ST7554 USB Modem".
I suppose you should first check this driver and an existing device node /dev/slusb0.
Here shortly again what your installation does. It's not to much.
1.)
Having a driver in binary form (i.e. a *.ko file) or as source file (an ASCII text *.c file) from CD. If it's a source file it has to be compiled (with the programm "make") but then you're sure it's fits into your kernel.
2.)
Loading this driver with "insmod -f driver_name.ko". If this fails there is no way around. You would have to get a new binary.
3.)
This driver should create a device node in the /dev dirrectory. With this device node the modem software (kppp e.g.) communicates with the modem hardware. So, if kppp sends a data packet, the kernel gets it with help of the driver on the device node and forwards it to the modem hardware.
So, kppp writes to and reads from the file /dev/slusb0 (or linked to /devmodem) as it would be a standard file and doesn't care about anything else.
4.)
You have to tell kppp what device node it has to use.
That's not much but if points 2 or 3 fail there is nothing to circumvent this.
I guess you see now at least the cornerstones of what is going on. So you can check what the setup software has done.
If you got stuck then ask again. No problem at all.